2

We're working with git in a "master" and multiple branches strategy. How many branches? A lot, some quite long living (10 long living "team" branches and 20-30 short living branches off them is normal).

I would like to see a merge of all of the "active" branches (a list of branches I know that are active) - I don't care if this doesn't compile or if some merges fail - I want to see "the big picture".

I've tried working with "checkout master; checkout %branch% -- ." - but I can do that for a single branch since the next branch I'll look at will override the %branch%. Moreover, because of one branch updating from another, I end up looking at the same changed file multiple times.

My next try was to use merge-base between branches I've seen and the next branch. So if I've seen branch1, then my flow is "checkout master; reset --hard; checkout branch1 -- .; (review branch 1); merge-base branch1 branch2 (emits commitX); reset --hard; checkout %commitX%; checkout branch2 -- ." That would leave branch2 as changes (for my review) but would leave out everything in branch1.

Above is great - but... 1. Identifying the order of branches to do this is hard (working with rule-of-thumb right now). 2. This is very time consuming and error prone. 3. If I make a mistake (choose the wrong branch to start from) I still get to review the same changes twice.

Is there any methodology / tool to aid in such tasks?

Jean-François Fabre
  • 137,073
  • 23
  • 153
  • 219
Ran Biron
  • 6,317
  • 5
  • 37
  • 67

1 Answers1

1

I would recommend, on your local repo only, to rebase those branches on top of master.
With a rebase, commits from one branch which were already applied (by the rebase of another branch) won't be replayed.
So the order of rebase don't matter so much (as opposed to multiple merges).
Plus, if you activate git rerere, you can memorize any merge conflicts that could occur, in order to not have to solve it again.

See also "Git: How to rebase many branches at once?".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Tested - have issues with conflicts. As said above, I don't care about specific file conflicts - I want to see the big picture. However, on rebase I can either fix each conflict (time-expensive) or skip the entire commit (discarding too much of the change). Any tips on that? – Ran Biron Feb 03 '14 at 08:42
  • @RanBiron you could also chose a merge strategy (like ours) in order to not interrupt the merge in case of conflicts (and see the big picture at the end): https://github.com/git/git/blob/master/Documentation/merge-strategies.txt – VonC Feb 03 '14 at 08:44
  • which strategy would you recommend? Oops - just saw you wrote "ours" - but in rebase "ours" means override the entire commit with the target commit, no? – Ran Biron Feb 03 '14 at 11:41
  • @RanBiron yes: "ours" but just to get to the end of the rebase. After that, you can cancel the rebase and redo it whenever you want, this time resolving the conflicts. – VonC Feb 03 '14 at 11:52
  • no dice. A commit being fully overridden by existing data (a pervious commit) is making me lose too many changes for the whole effort to be useful. – Ran Biron Feb 06 '14 at 08:49