Setting students up for code reviews


(Swift One) #1

My git knowledge is not as strong as it should be and the docs I find are great but very generic and don’t easily lead me to my desired workflow.

I want to create a private repo for each student, such that when they put in a pull request I will be able to code review it for them before it is merged. However, my experiments have not really panned out. (I’m at command-line git).

  1. Create the private repo, and set master to protected and review required - got it
  2. Invite the student - got it
  3. student clones repo - got it
  4. student creates a branch - got it (“git checkout -b `branch-name”, do I/they need to specify more?)
  5. student adds/commits - got it
  6. student pushes - Lost here. (“git push” fails, as does “git push origin”, and “git push origin HEAD:master” feels too cumbersome to be the norm, and “git push origin branch-name” is okay, I guess…)

I’m trying to get a push that will create a pull request, or at least inform them they need to go to the website and create one. As it is from the command line they have no clue a PR is required, and if I notice the new branch and start the PR for them, I can’t code review (because I’m the one requesting).

Also - what is the most painless way for them to pull changes in? (“git pull” complains about setting upstream, is there a way to set that when they create the clone and/or branch?)

I’m assuming this is very easy and I’m just a bit lost. Help appreciated! Thanks in advance.


(Vanessa) #2

Hi @SwiftOne

Two things to note:

  1. student pushes - Lost here. (“git push” fails, as does “git push origin”, and “git push origin HEAD:master” feels too cumbersome to be the norm, and “git push origin branch-name” is okay, I guess…)

So the master is protected, they won’t be able to push to that. And they’ll need to set up their own origin to push to the branch name, so your instinct to use git push origin branch-name is :100:

or…

git push -u origin branch-name

I’m trying to get a push that will create a pull request, or at least inform them they need to go to the website and create one. As it is from the command line they have no clue a PR is required, and if I notice the new branch and start the PR for them, I can’t code review (because I’m the one requesting).

Pull requests are a GitHub (versus a Git) feature. But if you want to install a package that will enable that command, check out: https://hub.github.com/

Also - what is the most painless way for them to pull changes in? (“git pull” complains about setting upstream, is there a way to set that when they create the clone and/or branch?)

Some teachers have had success with the add as remote method:


(Adriana) #3

@SwiftOne you can have students make their own branch and push to their branch with:

  1. git branch nameOfBranch this makes the branch
  2. git checkout nameOfBranch this switches from the master branch to the student’s personal branch
  3. git push origin nameOfBranch this pushes to the student’s personal branch onto github

After you do that the student can make pull requests to the original repository by choosing their branch and the master to make pull requests.


Student deleted repo accidentally and couldn't recreate
(Ryan B. Harvey) #4

While the above answers are correct, I wanted to add a note about the common practice here.

When a team is working together on a common codebase, if the origin repo is protected (i.e., collaborators can’t push code to it) the way this work usually happens is:

  1. The collaborator forks the repo to their own account.
  2. The collaborator creates a branch for what they’re doing.
  3. The collaborator codes away, completing the task and ensuring any tests are passing.
  4. Once ready, the collaborator can optionally merge the branch into their own copy of the master branch in their fork. This isn’t required, as the next step can be done from the branch as well.
  5. The collaborator creates a pull request on the origin repo for their changes, which is a request to merge the changes from their branch into the master branch on the origin repo.
  6. Code review and discussion happens in the pull request. Any concerns are mitigated by code changes on the collaborator’s repo, and are automatically added to the pull request.
  7. The changes are approved by the origin repo owner, and they merge the changes into the origin’s master branch and close the pull request. When merged, commits are attributed to the author, as on their own branch.
  8. The collaborator optionally deletes their branch from their copy of the repo, or even their fork of the repo. This is not required, but some people like to keep their accounts clean.

Hope this helps. Good luck!