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...

Forbearance

have you tried the answer? – Depilate

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'?

Depilate

Hi Androider, Thanks for spending time to help me. Actually I found out that I didn't lose all of my changes, and just that I need to merge in each commit level to decide which commit to take and which commit to ignore. Hence I am still resolving those and running rebase continue. I don't know what will happen if we rebase a branch on its own. Can you please provide some info of point me to an article explaining that? Again thanks a lot for providing valuable suggestions to resolve my problem :) – Forbearance

I updated the answer. It is not necessary to do the step I named rebase a branch with itsel. But if you yet have problems, and it is not able to do rebase properly, wold be useful to improve the answer see the log of your two branches (master and branch-A). At least the last commits of these branches. – Depilate

Thanks lot for providing more info. Since there were large number of commits on both master and my branch, I had to resolve each of those commits and run, git add and rebase --continue instead of commiting ( as rebase --continue itself is doing that). After doing that, all the conflicts are resolved and I merged back my branch with master. – Forbearance

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.

Inanimate

Answer 3

What worked for me is squashing my commits from where I branch from main:

1. look at the log to get the commit before your branches first commit
2. reset --soft
3. git commit -m "....squashed my commits"
4. git push --force
5. git checkout master
6. git pull
7. git checkout my-branch
8. git rebase master

Potluck