Menu
I'm trying to follow the Git work-flow described here: http://nvie.com/posts/a-successful-git-branching-model/
After finishing one feature and merging it int to my development branch, I updated a different feature branch using git rebase.
This seemed to work fine, but now I tried to push new changes on this feature branch to its origin counter part and I get the following error:
! [rejected] open-sea-dragon-feature -> open-sea-dragon-feature (non-fast-forward)
error: failed to push some refs to '[email protected]:jeffreycwitt/lombardpress2.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
My tree looks like this: 
In the picture you can see the two subsequent commits for the open-sea-dragon feature, after the rebase, were placed after the tip of the develop branch on my local machine. But this didn't happen for the origin counterpart and now they are out of sync.
I'm wondering how I can my feature branch back in sync with the origin feature branch.
242
The Rebase Option This moves the entire feature branch to begin on the tip of the main branch, effectively incorporating all of the new commits in main . But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
No, locally rebasing doesn't change the remote. @jonrsharpe So basically, I have to push to remote branch again after the rebase?
If the feature branch you are getting changes from is shared with other developers, rebasing is not recommended, because the rebasing process will create inconsistent repositories. For individuals, rebasing makes a lot of sense. If you want to see the history completely same as it happened, you should use merge.
Changing older or multiple commits. To modify older or multiple commits, you can use git rebase to combine a sequence of commits into a new base commit. In standard mode, git rebase allows you to literally rewrite history — automatically applying commits in your current working branch to the passed branch head.
That's exactly why you should not rewrite the history of already-published branches. You now have two options:
If you are absolutely sure that no one but you is working off your remote branch (i.e. origin/open-sea-dragon-feature), you can force-push your updated branch:
git push --force origin open-sea-dragon-feature
In your case, you will "lose" two commits during this procedure, but that should be alright here, because their rebased counterparts are included in the new branch.
Again: don't do this if other people may have already pulled the remote branch! They will get into a boatload of trouble when suddenly pulling a rewritten history.
If you cannot force-push your updated branch (for reasons said above), you'll need to bite the bullet and merge the remote branch:
git merge origin/open-sea-dragon-feature
After that, you'll be able to push with a simple fast-forward merge and other collaborators that use the branch will be able to easily pull your changes.
This will lead to some duplicate commits appearing in your history. Git should handle the differences though and be able to perform a clean merge. If the rebased commits are identical diff-wise, you should not get any conflicts while merging.
188
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
