0

I wanted to summarize a quick discussion we had in my stand-up today. We have a big feature branch merge coming up in our system. We are replacing the old live, system (branch master) with a redesign (branch feature/v1). In addition, there are 2 other branches--feature/celery branched from feature/v1 and feature/aggregates branched from feature/celery--that also need to be code reviewed and checked into master at some point. We can proceed by doing 2 paths: 

  1. Review and merge feature/v1 into master, review and merge feature/celery into master, then review and merge feature/aggregates into master
  2. Review and merge feature/aggregates into feature/celery, review and merge feature/celery into feature/v1, review and merge feature/v1 into master

Both paths have all changes going into master reviewed. The benefits of path (1) are that all changes are reviewed exactly once and each PR is treated as its own feature. The benefits of (2) are that it more closely resembles how this feature was actually developed (and the history tree might look a tad nicer). Both are equivalent in the end result they produce.

My personal choice is (1) because it leads to less duplicate reviewing which means its less likely something gets missed because we got lazy. Every diff we see is important.

It's a bit of pedantry because the end result is the same but wanted to gather some opinions on the pros and cons of each as well as factors I might be missing.

  • This is opinion based, not exactly something we can give an answer to. Personally I've used both approaches, and frankly the tree generated does not look qualitatively different, there are lines of straight commits and snarls of merge commits. Pull Requests just materialise out of thin air. I merge based on what is happening. If feature/celery is going out with feature/v1 merge them first. Otherwise don't merge them. I also prefer pre-merging, merging the branch that will be delivered too into the development branch, that allows testing and patching before delivering with a fast-forward. – Kain0_0 Mar 22 at 5:51
  • 1
    Does the master branch have any development you need to keep, or could you just declare v1 as the new master? – amon Mar 22 at 16:41

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.