43

I understand that when I use git pull --rebase, git will re-write history and move my local commits to occur after all of the commits in the branch I just pulled from.

What I don't understand is how this would ever be a bad thing. People talk about getting in to trouble with git pull --rebase where you can end up with a branch that other people can't pull from. But I don't get how that's possible since all you're doing is replaying your local, not-yet-public, commits on top of the branch you pulled from. So, what's the problem there?

Improve this question

4 Answers 4

Reset to default
28

It is only an issue if you have only published (pushed) some of your commits, because they would be harder to merge to other repos which have already those commits. Since their SHA1 have changed, Git would try to replay them again on those repos.

If you have not (pushed any of those commits again), any rebase should be safe.

So the issue here is: are you sure that all the local commit you are rebasing are still actually... local?
And are you sure of that 'git pull --rebase' after 'git pull --rebase'?

If you are working on a 'private branch' (a branch that you never pushed, but only merge or rebase on a public branch, one that you will push), then you are safe to rebase that private branch any time you want.

In the end, it all depends on the workflow of merge you have chosen to establish.

Improve this answer
7
  • 2
    Not necessarily safe, git pull --rebase can actually lose commits it tried to rebase if it fails.
    – ben
    Apr 10, 2010 at 23:42
  • What do you mean with fails here?
    – Marius K
    Jul 21, 2011 at 10:55
  • 1
    @Marius: good question (for ben, but it has been here the past two months). Whatever failure ben is talking about, there still is the reflog to get back your original commits of the private branch you just rebased.
    – VonC
    Jul 21, 2011 at 11:17
  • @ben: see Marius question in the comments.
    – VonC
    Jul 21, 2011 at 11:18
  • 1
    @djechlin a local repo can have multiple upstream remote repos; if you have pushed those commits elsewhere before doing your git pull --rebase, your next push to be of those upstream repos will be forced. But even with only one upstream repo, the idea is: if some of your commits, that you are rebasing, were part of another branch that you have already pushed, then it is a problem. The branch you are working with (and git pull --rebase) is fine. The other branches aren't.
    – VonC
    Mar 8, 2013 at 6:21
5

Commit to a branch. Push. Merge up to another branch (say you're maintaining two baselines, a patch branch and a new-development branch). Realize other commits have been pushed to the server branch yours is tracking. pull --rebase. Suddenly you've re-made each of the commits against the new hash - and destroyed the merge commit.

Improve this answer
3
  • 1
    But won't using option "--preserve-merges" to rebase avoid this? Unfortunately it seems it can't be configured in the config file. Not sure if it works with "git pull --rebase" either.
    – Marius K
    Jul 21, 2011 at 11:47
  • 1
    I've experienced this scenario few minutes ago... How can we avoid it?
    – gawi
    Mar 21, 2012 at 18:14
  • 1
    Just check out manuals for such commands git pull --rebase=preserve, git config --global pull.rebase preserve (you can skip key --global if you need).
    – Victor Yarema
    Apr 21, 2016 at 10:40
4

If nobody has pulled from you, and you have not pushed your commits (before rebase) anywhere else, then you are theoretically okay. However, Git is designed to handle merges well and you may find there's less work overall if you pull and merge instead of pull and rebase.

Improve this answer
2

Remember that Git is a distributed source control system. People don't have to pull from the central repository that you're pushing to - in certain workflows they can pull their changes directly from you. In those cases, rewriting your history can certainly cause the problems you're talking about

Improve this answer
1
  • Even in such case it is possible to do rabase on receiving side to avoid inconsistencies.
    – Victor Yarema
    Apr 21, 2016 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.