posts/git-rebase-intro/

[utterances-bot]

Git Rebase 操作浅析 | Shall We Code?

以前我对 git rebase -i 的用法一直是一知半解，一次在需要合并多个提交时刚好用到，一顿操作差点把提交都搞丢了，幸好后面顺利找回，因此记录一下……

https://www.waynerv.com/posts/git-rebase-intro/
6a5c7660cc901232934675bee135bc0222015ee5

[ryanqy]

文章中的

否则其他人之后执行 git pull 会把他们本地的提交历史也覆盖掉

在什么情况下会发生覆盖的情况呢

[ryanqy]

看到国内很多文章都是写的，对于已经push到公共仓库的提交进行rebase操作，会导致他人的提交丢失，例如掘金的这篇文章，但我不是很明白，这篇文章种列举的情形下为什么会有提交丢失? git pull 的操作大致等同于git fetch 和 git merge （如果不使用git pull --rebase）, 这种情形下不是仅仅使用three way merge的方式进行merge么？为何出现提交丢失了？

[waynerv]

@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/

[fengqiangzhao]

感谢博主分享，很多文章都不推荐rebase 操作 远程仓库的commit，理由是会搞乱分支。
我个人理解是这样的，rebase 的目的是保证分支提交清晰美观，而merge的目的是保证提交的原始性，原汁原味的。
多人协作的项目开发中，同事A对远程分支的commit进行了rebase -i修改或者压缩，并强制push到远程仓库，这时候如果同事B在pull代码的时候不使用-rebase方式的话，就会在本地产生一个merge提交,并且同事A rebase操作都还原回来了，这时候如果B推到远端，A做的rebase操作就不见了

[waynerv]

感谢博主分享，很多文章都不推荐rebase 操作 远程仓库的commit，理由是会搞乱分支。 我个人理解是这样的，rebase 的目的是保证分支提交清晰美观，而merge的目的是保证提交的原始性，原汁原味的。 多人协作的项目开发中，同事A对远程分支的commit进行了rebase -i修改或者压缩，并强制push到远程仓库，这时候如果同事B在pull代码的时候不使用-rebase方式的话，就会在本地产生一个merge提交,并且同事A rebase操作都还原回来了，这时候如果B推到远端，A做的rebase操作就不见了

你的理解是对的 😄

[KingOfBanana]

动图很不错，直观！

[HUAHUAI23]

博主，文章的动图是用啥软件生成的呀

[waynerv]

https://git-school.github.io/visualizing-git/