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?
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.