10

I'm introducing git to a junior team member (a co-op).

They are comfortable now with the basics of adding, committing, pushing and pulling.

Now I want to introduce them to pull requests and branches.

If they start doing pull requests in branches, should I do the same for my on-going work?
I will be the one merging their pull requests in. I wasn't sure if it would make the most sense for me to work in branches (generally a good practice I know but I am curious about this specific situation of 2 devs with one junior) and if so does that mean that I'll just be merging my own branches into master. Would I even do a pull request for my work / branches anyway? Generally we use the basic github Feature Branch Workflow for these changes:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Is there a purpose for using pull requests on my own repo if I am the only developer? is useful but not quite as specific.

Whats the work flow with 2 people on a project also seems more general

and

Should I open pull requests from a branch on the official repo or my fork? seems more about forks.

18

No. You should not merge your own pull requests. What's good for the goose is good for the gander. Merging your own pull requests sets a bad precedent for our junior dev. It also means that no one else is looking at your code. No matter how senior we may be, we all makes mistakes and write bad code from time to time. Teach your junior how code reviews work from the other side by making him review and merge your work.

He may not have the same eye you do, but it will get him accustomed to the process from the reviewer's end and he may surprise you and catch something stupid you did. Minimally, it will give you an indication of pieces of code that are obvious to you, that aren't obvious to him. This has a two fold benefit.

  1. You both learn where your junior needs to focus learning activities.
  2. You learn where you're being more clever than you should be.
  • 6
    The other huge benefit of code reviews is that at least two people have seen, know about and had a chance to ask questions about every single code change before it goes in. Even if the junior dev doesn't know what to look for, he's guaranteed to learn something from all of that. – Ixrec Aug 2 '15 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.