When will `git pull --rebase` get me in to trouble?

对着背影说爱祢 提交于 2019-11-27 03:53:53
VonC

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.

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.

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.

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

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!