Closed utterances-bot closed 2 years ago
文章中的
否则其他人之后执行 git pull 会把他们本地的提交历史也覆盖掉
在什么情况下会发生覆盖的情况呢
看到国内很多文章都是写的,对于已经push
到公共仓库的提交进行rebase
操作,会导致他人的提交丢失,例如掘金的这篇文章,但我不是很明白,这篇文章种列举的情形下为什么会有提交丢失? git pull
的操作大致等同于git fetch
和 git merge
(如果不使用git pull --rebase
), 这种情形下不是仅仅使用three way merge
的方式进行merge
么?为何出现提交丢失了?
@ryanqy 感谢提问,我思考了之后觉得这里用「覆盖」一词并不准确,因为这种操作并不会「丢失」提交,只是会搞乱提交历史。具体会发生的情况是这样的: 假设有一个远程分支是:A->B->C->D,甲先拉取了该分支到本地,然后乙拉取了分支并执行了 rebase -i,修改了 A 之后的提交历史(这里假设只是修改了 B 的提交信息),并通过 force-push 强制推送到了远程分支,此时远程分支会变成 A->B'->C'->D',如果甲再执行 git pull,实际上甲本地 A 之后的提交都会被当成新的提交,因此需要执行一次 merge,merge之后会变成:
A->B'->C'->D'->M
\ /
B -> C -> D
所以你的理解是正确的,另外有一篇英文博客对这种情况解释的更加全面,你可以看一下:https://www.daolf.com/posts/git-series-part-2/
感谢博主分享,很多文章都不推荐rebase 操作 远程仓库的commit,理由是会搞乱分支。 我个人理解是这样的,rebase 的目的是保证分支提交清晰美观,而merge的目的是保证提交的原始性,原汁原味的。 多人协作的项目开发中,同事A对远程分支的commit进行了rebase -i修改或者压缩,并强制push到远程仓库,这时候如果同事B在pull代码的时候不使用-rebase方式的话,就会在本地产生一个merge提交,并且同事A rebase操作都还原回来了,这时候如果B推到远端,A做的rebase操作就不见了
感谢博主分享,很多文章都不推荐rebase 操作 远程仓库的commit,理由是会搞乱分支。 我个人理解是这样的,rebase 的目的是保证分支提交清晰美观,而merge的目的是保证提交的原始性,原汁原味的。 多人协作的项目开发中,同事A对远程分支的commit进行了rebase -i修改或者压缩,并强制push到远程仓库,这时候如果同事B在pull代码的时候不使用-rebase方式的话,就会在本地产生一个merge提交,并且同事A rebase操作都还原回来了,这时候如果B推到远端,A做的rebase操作就不见了
你的理解是对的 😄
动图很不错,直观!
Git Rebase 操作浅析 | Shall We Code?
以前我对 git rebase -i 的用法一直是一知半解,一次在需要合并多个提交时刚好用到,一顿操作差点把提交都搞丢了,幸好后面顺利找回,因此记录一下……
https://www.waynerv.com/posts/git-rebase-intro/