I have two branches, newfeature and release. I work with a team so I need to pull from release every so often to get updates. To do this, I run a git pull origin release from my local newfeature branch. From here I resolve merge conflicts in VSCode by choosing either current or incoming changes. This is using the rebase process.
Upon finishing this process I run a git push origin newfeature. When I do this it says I need to pull the latest since there are conflicts. I run a git pull origin newfeature to get the latest and resolve conflicts. When I finish up the rebase , I finally am able to push to origin/newfeature to make sure it's up to date.
To double check that both branches are compatible, I run another git pull origin release to make sure all conflicts are resolved. Unfortunately, it says that there are conflicts and I have to repeate the process again. To avoid this issue, I've been pulling release and using git push origin newfeature --force to make sure it's up to date. I've read that using --force is not recommended since git is trying to tell me that there are conflicts.
My question is, how do I get out of this rebase loop?
CodePudding user response：
TLDR
After you rebase, you must force push your branch. You cannot do a normal push. Trying to do so is the root cause of your problem.
Original longer answer with some assumptions
It sounds like you are following these steps:
git checkout newfeaturegit pull origin release- Resolve conflicts
git rebase release- Resolve conflicts again
git push origin- Gives an error that you need to pull
Let's clarify what is going on here.
git pull is essentially git fetch followed by git merge. This is why you have to resolve conflicts. This is a standard part of merging the primary branch into a feature branch.
This by itself is sufficient. You can immediately do a git push and carry on with your day.
This creates a somewhat messy history tree with periodic merge commits. So some developers like to use git rebase to keep their changes in a linear history for each feature. And some projects will require this, especially when contributing to open source projects.
The key here is DO NOT COMBINE A git pull AND A git rebase. Do one or the other, but never both.
The correct way to rebase is like this:
git checkout newfeature
git fetch
git rebase origin/release
Then resolve conflicts for each commit as they are rebased. Notice that I use the origin/release remote tracking branch rather than the local release branch. This ensures that the rebase is on top of all of the work that has been merged into the remote release branch.
Note that a rebase will rewrite your feature branch history. So now you have to do git push -f. If you do git push after a rebase, then you will get the error message that is leading you to this infinite rebase loop.
You are right that you must be cautious about using git push -f. This is because you are now introducing an alternative history for your branch. If any of your teammates are working on the same branch with the old history, then they will encounter merge conflicts the next time they try to push their work to the central repo.
On the other hand, if you are the only person on this project or if you are sure that none of your teammates have pulled this branch, then you can safely force push. Also if you communicate with your teammates about your desire to force push, they can mitigate any problems on their side.
CodePudding user response：
git rebase is an action that changes the history of commits on the branch you are working on. When you work with a local branch which tracks a remote branch, this generally means that you will need to force push to update the remote branch.
Your workflow should probably be :
git fetch origin
git rebase origin/master
# fix conflicts if any
# test the resulting branch
git push --force-with-lease origin newfeature