优秀！原来华为是这样使用 git rebase的( 二 ) 原文：使用git参与多人之间的

这里需要留意到的一个现象是 develop 和develop_a 分支上相同提交的commit id 已经发生了变化，这个在后面会再次提到。
文章插图
除了修改提交的commit msg 之外，我们也可以通过把pick 改为e ，结合git reset --soft HEAD^ 的方式对档次提交的改动内容进行修改。
合并与删除历史提交的操作步骤与编辑类似，只需要把pick分别改为s 和d 即可，各位看官可以自行尝试。如果在rebase的过程中遇到了冲突，需要手工解决，然后使用git rebase --continue 完成rebase 操作。
git rebase 的提示还是非常友好的，它会告诉你需要进行哪些操作解决当前的问题。
文章插图
使用git rebase -i 必须遵循的规则是什么？从修改历史提交记录这个功能来看，交互式变基是一个非常强大的功能。但是使用这个功能必须要遵循一个铁则：不要对线上分支的提交记录进行变基！
引用git 官方指导文档的话来说大概是这样：
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
在说为什么不能对线上提交执行交互式变基之前，先说一下如果要对线上功能执行这个操作要怎么做。
首先，你需要在自己本地变基成功，然后使用git push -f 强行push 并覆盖远程对应分支，之所以需要执行覆盖式push 是因为如果你不覆盖，当前变基过后产生的新提交会与远程合并，导致你在本地的变基行为失去意义。
因为我们上面提到过，从变基那个节点开始往后的所有节点的commit id 都会发生变化。
同样的原因，即使你使用git push -f 使远程分支发生了变基，如果你的同事的开发分支中还存在你执行变基操作（不论是修改、合并还是删除）时针对的那些分支，那么当你的同事merge 你的提交之后，你所有想使用变基改变的东西都回来了！
如果打破了git rebase -i 的使用规则应该如何补救此处我们尝试通过要点描述的方式，说明线上提交执行变基会导致什么结果以及如何避免这个结果：
（1）你在本地对部分线上提交进行了变基，这部分提交我们称之为a ， a在变基之后commit id 发生了变化
（2）你在本地改变的这些提交有可能存在于你的同事的开发分支中，我们称之为b ，他们与a的内容相同， commit id 不同
（3）如果你把变基结果强行push 到远程仓库后，你的同事在本地执行git pull 的时候会导致a 和b 发生融合，且都出现在了历史提交中，导致你的变基行为无效
（4）我们想要的是你的同事拉取线上代码时跳过对a 和b 的合并，只是把他本地分支上新增的修改合并进来
讲了这么多，最终的结论就是，使用变基解决变基带来的问题。即你的同事使用git rebase 的方式把他本地的修改rebase 到远程你执行过rebase 的分支上。
简言之，就是你的同事使用git pull --rebase 而不是git pull 来拉取远程分支。在这个操作的过程中， git 会对我们上面提到几个要点的信息进行检查并把真正属于同事本地的修改合入远程分支的最后。
文字描述可能有些乏力，更多详细信息可以参考这里：git-scm.com/book/zh/v2/…
所以我们应该如何使用git rebase鉴于上面描述的git rebase 可能带来的问题，最后要回答的一个问题是我们应该如何在日常工作中使用git rebase ，同样借用git 官方文档中的一句话：
【优秀！原来华为是这样使用 git rebase的】总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式（rebase 和merge）带来的便利。