42

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?

Gabe Hollombe
  • 7,847
  • 4
  • 39
  • 44

4 Answers4

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 2
    Not necessarily safe, `git pull --rebase` can actually lose commits it tried to rebase if it fails. – ben Apr 10 '10 at 23:42
  • What do you mean with fails here? – Marius K Jul 21 '11 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 '11 at 11:17
  • @ben: see Marius question in the comments. – VonC Jul 21 '11 at 11:18
  • I'm not understanding what "published some of my your commits" mean. This is unclear to me because I've of course published several hundred. But once there's any outstanding change on the branch I'm working on, git push fails unless I force. Does this mean it's always safe if 1) we only pull from a centralized repo and 2) never push-force? – djechlin Mar 07 '13 at 23:53
  • 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 08 '13 at 06:21
  • @ben, `git pull --rebase` can loose commits only in two cases. 1. The commit brings changes that are already applied to code somewhere in base (history you are rebasing onto). 2. You did some mistake while applying commit during rebase. – Victor Yarema Apr 21 '16 at 10:46
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.

John Stoneham
  • 2,485
  • 19
  • 10
  • 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 '11 at 11:47
  • 1
    I've experienced this scenario few minutes ago... How can we avoid it? – gawi Mar 21 '12 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 '16 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.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
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

Gareth
  • 133,157
  • 36
  • 148
  • 157