4

Here is our current feature branch work flow ->

  • From the master create a new feature branch.
  • Commit work to the feature branch.
  • Merge the master into the feature branch as we work to keep it up to date.
  • If there are conflicts resolve them. This creates a "Merge master into Feature_Branch" commit in the feature branch.
  • When the feature branch is complete, merge the feature branch back into master.

Problem:

If we do a merge --squash of the feature branch into the master, we have no issues. If we do a regular merge and then rebase we have to resolve all the conflicts again. On a feature branch with 100's of commits this is a major pain.

Is there a way to merge the feature branch back into master and rebase without conflicts?

Kenoyer130
  • 6,874
  • 9
  • 51
  • 73

1 Answers1

5

I think you are fighting with this thing: Rebasing a Git merge commit

Try enabling rerere and using git rebase with -p option.

If I understood well, -p asks Git to try reusing previously-stored conflict resolutions upon stumbling on them during rebase, and rerere is a, say, "plugin", that enabled git to, literally, "REuses REcorded REsolutions".

Sometime ago there was an article here but it seems down now. Maybe you'll find that on internet-archive.

So, I've just looked up another one, it seems to explain things nicely:

Rerere Your Boat...

i.e.:

With rerere turned on you can merge occasionally, resolve the conflicts, then back out the merge. If you do this continuously, then the final merge should be easy because rerere can just do everything for you automatically.

This same tactic can be used if you want to keep a branch rebased so you don't have to deal with the same rebasing conflicts each time you do it. Or if you want to take a branch that you merged and fixed a bunch of conflicts and then decide to rebase it instead - you likely won't have to do all the same conflicts again.

See the highlight. Seems just what you are doing.

But, before you jump with "geez, why isn't that enabled by default?!" take some care and see also this : https://stackoverflow.com/a/5521483/717732 and along with rerere learn the rerere forget. Just in case!

Community
  • 1
  • 1
quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107
  • git rebase -p doesn't seem to move the feature branch commits to the top :/ – Kenoyer130 Nov 13 '13 at 16:53
  • I'm sorry, I just don't understand. What "top"? Which commits? You mean normal commits, or 'conflict resolution' commits? I'd suggest you expand your original question with some examples and results.. – quetzalcoatl Nov 13 '13 at 18:49
  • top as in move the branch commits after the head of the branch we are merging into. In this case master. – Kenoyer130 Nov 27 '13 at 12:37
  • 1
    You mean, like having `a-b-c-d-e` with feature branch `c-x-y-z`, and rebase on that branch on top of the master did not result in `a-b-c-d-e-x-y-z`? Now that's strange. It definitely should have done that. What was the result then? Where the x-y-z were moved to? I really think you should present the states (either log with hashes, or letters ABCDE..) and commandlines.. – quetzalcoatl Nov 27 '13 at 14:01
  • 1
    As of 2022, g rebase -p , gives this error message: warning: git rebase --preserve-merges is deprecated. Use --rebase-merges instead. – Deekshith Anand Feb 22 '22 at 05:51