Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
OK, I thought this was a simple git scenario, what am I missing?
I have a
master
branch and a
feature
branch. I do some work on
master
, some on
feature
, and then some more on
master
. I end up with something like this (lexicographic order implies the order of commits):
A--B--C------F--G (master)
D--E (feature)
I have no problem to git push origin master to keep the remote master updated, nor with git push origin feature (when on feature) to maintain a remote backup for my feature work. Up until now, we're good.
But now I want to rebase feature on top of the F--G commits on master, so I git checkout feature and git rebase master. Still good. Now we have:
A--B--C------F--G (master)
D'--E' (feature)
Problem: the moment I want to backup the new rebased feature branched with git push origin feature, the push is rejected since the tree has changed due to the rebasing. This can only be solved with git push --force origin feature.
I hate using --force without being sure I need it. So, do I need it? Does the rebasing necessarily imply that the next push should be --forceful?
This feature branch is not shared with any other devs, so I have no problem de facto with the force push, I'm not going to lose any data, the question is more conceptual.
The problem is that git push assumes that remote branch can be fast-forwarded to your local branch, that is that all the difference between local and remote branches is in local having some new commits at the end like that:
Z--X--R <- origin/some-branch (can be fast-forwarded to Y commit)
T--Y <- some-branch
When you perform git rebase commits D and E are applied to new base and new commits are created. That means after rebase you have something like that:
A--B--C------F--G--D'--E' <- feature-branch
D--E <- origin/feature-branch
In that situation remote branch can't be fast-forwarded to local. Though, theoretically local branch can be merged into remote (obviously you don't need it in that case), but as git push performs only fast-forward merges it throws and error.
And what --force option does is just ignoring state of remote branch and setting it to the commit you're pushing into it. So git push --force origin feature-branch simply overrides origin/feature-branch with local feature-branch.
In my opinion, rebasing feature branches on master and force-pushing them back to remote repository is OK as long as you're the only one who works on that branch.
–
–
–
–
--force-with-lease
Why? Because it checks the remote branch for changes which is absolutely a good idea. Let's imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses --force and would rewrite all Lisa's changes. If James had used --force-with-lease he would have received a warning that there are commits done by someone else. I don't see why anyone would use --force instead of --force-with-lease when pushing after a rebase.
–
–
–
–
–
when you delete you prevent to push in an exiting branch that contains different SHA ID.
I am deleting only the remote branch in this case.
–
–
–
One solution to this is to do what msysGit's rebasing merge script does - after the rebase, merge in the old head of feature with -s ours. You end up with the commit graph:
A--B--C------F--G (master)
\ \
\ D'--E' (feature)
\ /
\ --
\ /
D--E (old-feature)
... and your push of feature will be a fast-forward.
In other words, you can do:
git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature
(Not tested, but I think that's right...)
–
–
–
–
–
Other's have answered your question. If you rebase a branch you will need to force to push that branch.
Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant.
In general, rebase works well for local branch management. Remote branch management works best with explicit merges (--no-ff).
We also avoid merging master into a feature branch. Instead we rebase to master but with a new branch name (e.g adding a version suffix). This avoids the problem of rebasing in the shared repository.
It may or may not be the case that there is only one developer on this branch, that is now (after the rebase) not inline with the origin/feature.
As such I would suggest to use the following sequence:
git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2
Yeah, new branch, this should solve this without a --force, which I think generally is a major git drawback.
–
–
–
–
My way of avoiding the force push is to create a new branch and continuing work on that new branch and after some stability, remove the old branch that was rebased:
Rebasing the checked out branch locally
Branching from the rebased branch to a new branch
Pushing that branch as a new branch to remote. and deleting the old branch on remote
–
–
–
What is wrong with a git merge master on the feature branch? This will preserve the work you had, while keeping it separate from the mainline branch.
A--B--C------F--G
\ \
D--E------H
Edit: Ah sorry did not read your problem statement. You will need force as you performed a rebase. All commands that modify the history will need the --force argument. This is a failsafe to prevent you from losing work (the old D and E would be lost).
So you performed a git rebase which made the tree look like (although partially hidden as D and E are no longer in a named branch):
A--B--C------F--G
\ \
D--E D'--E'
So, when trying to push your new feature branch (with D' and E' in it), you would lose D and E.
–
and it does not remove any of my code.
But, if you want to avoid this then you can do the following:
git checkout master
git pull --rebase
git checkout -b new_branch_name
then you can cherry-pick all your commits to the new branch.
git cherry-pick COMMIT ID
and then push your new branch.
Fetch new changes of master and rebase feature branch on top of latest master
git checkout master
git pull
git checkout feature
git pull --rebase origin master
git push origin feature
As the OP does understand the problem, just looks for a nicer solution...
How about this as a practice ?
Have on actual feature-develop branch (where you never rebase and force-push, so your fellow feature developers don't hate you). Here, regularly grab those changes from main with a merge. Messier history, yes, but life is easy and no one get's interupted in his work.
Have a second feature-develop branch, where one feature team member regulary pushes all feature commits to, indeed rebased, indeed forced. So almost cleanly based on a fairly recent master commit. Upon feature complete, push that branch on top of master.
There might be a pattern name for this method already.
rebase feature
git checkout -b feature2 origin/feature
git push -u origin feature2:feature2
Delete the old remote branch feature
git push -u origin feature:feature
Now the remote will have feature(rebased on latest master) and feature2(with old master head). This would allow you to compare later if you have done mistakes in reolving conflicts.
Apologise first, this is not an answer
Conventionally this should be an answer but I thought it would be important to emphasise that the answers aren't look like the right way to use rebase (some are valid workaround but aren't as elegant as we could expect from git).
"git force" - is dangerous, might override others work
Creating new branch - will require sync with others who work on this feature branch, miss the point of using git.
recreating the branch (after deleting it with or without a one-liner magic command), same problems as in #2.
"git merge" - rebase was designed to avoid/prevent merge commits in the log and keeping the git log clean and consistent.
Unfortunately, I don't have the answer (yet).
Between the above "git merge" is the only one that is safe for team work.
[Edit #1]
According to this great doc by Atlassian rebase should only be used for your local work
Don't rebase public history.
As we've discussed previously in rewriting history, you should never rebase commits once they've been pushed to a public repository. The rebase would replace the old commits with new ones and it would look like that part of your project history abruptly vanished.
[Edit #2]
According to this fine explanation it is an expected behaviour. Meaning that you might need to re-merge things that was already merged in the original commit.
If torec is right and if I got that right then I vote for the good old pull (fetch/merge) flow.
[Edit #3]
All the above can be correct depending on the scenario. If you are working on a feature branch with a friend, don't "push --force" but fetch and merge origin/feature1. If you work alone on a branch you can "push --force" and enjoy a pretty log.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
