11

I have my feature branch which has exceeded around 30 or more commits. Meanwhile in development branch few other features have been pushed from other developers. Therefore, Everytime a new feature is published on development, I am asked to:

  1. Rebase development branch onto my feature branch
  2. Resolve conflicts if any
  3. Continue developing in your feature branch

The problem

The second step is the chicken's neck here. On rebasing it gives me conflicts for every commit of that branch. This is really iterative and redundant. Note, I can't always rebase the development branch immediately since my own work in my branch remains in progress.

What I tried?

  1. To squash and reduce my commits as much as possible (but this helps least, as most of the times there is nothing to squash)
  2. To stash my on going changes, and rebase development and then unstash my changes. (but here, I get conflicts as well)
  3. Using -preserve-merges with rebase. (but everyone here shouts that using this is totally discouraged)

So, what is the optimal approach in dealing with rebasing development onto feature branch with least conflicts when the feature branch itself has numerous commits. I am a fresher, and so a reply with a helpful explanation (or link) will be of much help to proceed.

Karan Desai
  • 3,012
  • 5
  • 32
  • 66

3 Answers3

7

The workflow is sound (rebase).
But the conflicts should not be resolved every time over and over again.

For that, you have git rerere: activate it (git config --global rerere.enabled true), resolve the conflict one last time (or do a manual re-training, or use contrib/rerere-train.sh), and your next rebase will resuse those conflict resolution at your next rebase.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Wow never heard about rerere ..Will try this for sure...Thanks – Karan Desai Aug 23 '17 at 05:38
  • 1
    @KaranDesai Again as I mentioned, you can retrain rerere in order to avoid having to resolve (again) your merge conflicts. Once the retraining is done, you can try again a rebase: there shouldn't be any more conflicts (on past commits) – VonC Aug 23 '17 at 06:35
3

I would suggest to keep your feature small (one or two days), and your feature branch will be small as well. Another way would be to rebase not every time something got pushed to development branch but only sometimes, or just once before the merge. Again you need to keep the feature small or you will have too many conflics all at once.

About your question, you cannot minimize the number of conflics in a rebase. If there are conflics you cannot avoid them.

But there is one way git can help you: I suggest you to enable rerere which stands for reuse recorded resolution. With this, git records how you resolve a conflict and the next time the conflict appears, the resolution is reapplied so that you find the conflict already resolved. This sould speed up your workflow.

You can enable rerere globally with

git config --global rerere.enabled true
Francesco
  • 4,052
  • 2
  • 21
  • 29
  • Woah rerere is not rare, that means (only I didn't know it). Same suggestion was in previous answer as well. +1 for adding syntax to enable it globally..Will surely try – Karan Desai Aug 23 '17 at 05:40
0

Try to git merge from the development branch into the feature branch before you perform the git rebase. It will be more informative in the way.

yorammi
  • 6,272
  • 1
  • 28
  • 34