I have a my-feature
branch that is pushed up to origin for code review. It is not shared. Eventually it will get merged into my develop
branch which is shared amongst my team. I'd like to rebase my develop
branch into my-feature
to keep the history cleaner and then merge my feature branch into develop. This is what I have been doing:
$ git checkout my-feature
// do some work. make commits.
$ git rebase develop
// fix some conflicts
$ git add .
$ git rebase --continue
After I have rebased successfully, I check the status:
$ git status
On branch my-feature
Your branch and 'origin/my-feature' have diverged,
and have 155 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
$ git what do I do here?
I have to idea what to do here. If I git pull
, then I've noticed that I will get some conflicts which doesn't make sense. Some people say to force push but I'm nervous about that. Is it normal to force push my topic branch to origin? So long as no one else uses that branch?
A branch in git is a series of interrelated commits. If two branches follow a non-linear path then they diverge each other.
Sometimes a branch has diverged from origin so much, that it doesn't make sense to try to resolve all the conflicts. In this case, it's better to just reset your local branch to whatever is on origin. To do this, you need to fetch first and then run git reset --hard origin/<branch> .
No, locally rebasing doesn't change the remote. @jonrsharpe So basically, I have to push to remote branch again after the rebase?
First, you can do a git push --force
at this stage without any worries: you have said your branch is not shared.
So changing its history on the server side won't affect any other user.
Second, when you rebase a branch, you change its common ancestor from with its remote tracking branch (origin/xxx
)
Before git rebase develop
, you have
d--d--d (develop)
\
x--x--x--x--x--X--y--y--y (my-feature)
|
(origin/my-feature)
X
is the common ancestor between origin/feature and feature, which simply means you have added a few commits in your my-feature
branch).
A git status would return something like:
On branch my-feature
Your branch is ahead of 'origin/my-feature' by 3 commit.
But when you rebase that branch on top of develop
, you replay all the commits of my-feature
on top of develop HEAD
X--X--X--X--X--X--Y--Y--Y (my-feature)
/
d--D--d (develop)
\
x--x--x--x--x--X
|
(origin/my-feature)
This time, the common ancestor between my-feature
and origin/my-feature
no longer is a few added commit, but the full history of my-feature
, plus some commits of develop
! (D
here)
Hence the status
Your branch and 'origin/my-feature' have diverged,
and have 155 and 1 different commit each, respectively.
Since your branch isn't shared, again, a simple git push --force origin my-feature
will complete the operation:
X--X--X--X--X--X--Y--Y--Y (my-feature, origin/my-feature)
/
d--D--d (develop)
(If my-feature
has an upstream branch, a git push --force
is enough, provided the default push policy push.default
is set to simple
.
Check that with git rev-parse --abbrev-ref --symbolic-full-name @{u}
)
What you're seeing is that my-feature
is indeed different than origin/my-feature
(what my-feature looked like on origin the last time you checked) because you just changed my-feature
(the my-feature you're working with) when you did the rebase.
When you do a rebase, you're changing the history of a branch so you'll almost always need to --force
push afterwards. It's fine if it's your branch and there aren't any collaborators using that branch.
If this feature branch does have collaborators, then you shouldn't have rebased to begin with. General rule of thumb is to not alter the history of shared branches. If this is the case, you'll need to undo the rebase, which you can refer to this post for help with.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With