Git rebase circles back to same place again and again

Question

I am having problem with Git rebase that I have to merge the code again and again but still unsuccessful.

I had cut of my branch (A) from master. I started working on my branch and made more commits. At the same time, master was also changed and underwent bunch of commits. Now I am trying to merge my branch back to master.

So I give,

git co master
git pull 
git co branch-A
git rebase master

Now I get messages like CONFLICT : Merge conflict in

With this, it branches into a new branch with name (no branch, rebasing branch-A) After this I resolve all the conflicts and then I give git add of all those files.

Now I get the status

rebase in progress; onto ad0da3f
You are currently rebasing branch 'branch-A' on 'ad0da3f'.
  (all conflicts fixed: run "git rebase --continue")

After this I run git rebase --continue and all the changes which I did to resolve the conflicts are gone and it goes back to the initial state of merging and throwing a huge bunch of Conflicts as before!

My question is,

1. How can I get back all the conflict resolutions that I have done before issuing git rebase --continue?
2. How can I not get stuck into the same loop requiring to merge again and again to pull the changes from master to my branch?

3. After I successfully merge all the changes from master to my branch, to merge my branch back to master, can I simply use,

   git co master git merge branch-A

Or do I need to issue any more commands?

Any help please...

Answer 1

To me, it's hard to say what is wrong with you, but follow this steps:

• First, make a backup of the folder where is your project, just if something goes wrong, you yet have the original local repository.

• Do a pull with rebase in master:

  git checkout master
  
  git pull --rebase origin master
  

• Rebase your branch with master:

  git checkout branch-A
  
  git rebase master
  

• And of course, if there is some conflict, resolve the way you are already doing.

When I say rebase a branch with itself, I'd like to say update your branch with remote. Of course if only you use branch-A, you don't need do pull or pull --rebase in your local branch. But in master it is a good practice using rebase to avoid merge commits that result from git pull. Of course do rebase cause some implications, for example when you push commits before do a rebase. So, the ideal, is make everything local, and only after rebase you push your branch or merge it with master. See The Perils of Rebasing.

In my case what I like to do is: after rebasing my feature branch with master, I checkout to master and do git merge <my-branch> --no-ff. This way my git history has a commit merge branch 'my-branch'. And I like my git history this way.

More information about merge vs. rebase see this answer for the question What's the difference between 'git merge' and 'git rebase'?

Answer 2

While it is always possible to rebase a new branch (before pushing to remote for the first time), rebasing later again (as the master branch advances) and pushing for the the second time seems not fully supported by git.

To be precise, in the latter case git complains that you need to pull before you can push (to your own remote branch where nobody else have committed any changes!), but once you pull you suddenly get the merge conflicts (with whom - with myself?), and here the hell begins ... I know few teams who switched back to merge from rebase because of these issues.

Hence once your branch has been pushed to remote, it is only reasonable to commit and push following changes (likely in response to the reviewer comments), but never rebase again. If the master branch advances so far that maintainer asks for the second rebase, all it can be done is rebase and then rename the branch. Then it can be pushed as new, also opening a new pull request.

Alternatively you can push with --force to wipe the remote copy and replace it with the current local content. However --force is somewhat frowned upon so I cannot say "recommended solution".

git is optimized for reviewing and merging the pull requests quickly. Possibilities to breed and hatch them for weeks and months still in a good shape against the master branch are limited.