In Git, we have a develop branch from which we make feature branches for each feature. I see two ways of merging the latest changes in develop with my feature branch code.

  1. Merge the latest develop code into my feature branch.
  2. Merge my feature branch into the local develop branch.

If I do the first way, the pull request I make for my feature for a code review includes the final merged code where changes in develop overlapped with changes in my feature, which is good, but now it also includes all the code changed in develop that I never touched. This makes it hard for the code reviewer to tell exactly what code they are supposed to be reviewing. Also, when I go to merge the feature back into develop, it looks like I'm committing a bunch of code that I never touched because I pulled it in from develop.

If I do it the second way, the pull request I make for my feature for a code review hasn't been merged and, therefore, the code reviewer isn't reviewing the code that will ultimately be pushed to develop.

Is there a way to have the best of both worlds, where the pull request I make has my code with any merge conflicts resolved, but doesn't list a bunch of files from develop that others worked on but that I never touched?

  • If you pulled commits from develop, they won’t appear as new when merging back to develop. They already are on develop, after all. – Daniel B Jan 22 '16 at 15:36
  • You shouldn't do either. The process of merging feature and the current development branch should be done, once the feature has been accepted as something your project intends on doing, which would ideally be done after a code review of just your feature code. The entire point is you performed a branch on a specific development commit, you would spend until the end of time, merging your feature branch into the ever changing development branch. As Daniel points out, only your feature changes would be reviewed, since that is the only thing that changed. Stand by my first half though. – Ramhound Jan 22 '16 at 15:37
  • @Ramhound, don't you feel uncomfortable approving unmerged code whose behavior might get changed once it is merged? – adam0101 Jan 22 '16 at 15:40
  • Its a development branch, it should be kept stable enough so all features work, but it also is a work in progress which means the only code not reviewed will be what is required to make it work. Eventually a second code review would be done to review all feature branch changes into the development branch compared to the stable branch I would resume. I presume you don't just send out development branch code to customers, depends on how flexible your project is, there are lots of thoughts on newer project management styles. – Ramhound Jan 22 '16 at 15:47

Your Answer

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

Browse other questions tagged or ask your own question.