两个分支合并的提交历史。 通过变基。变成线性的提交历史。 (上图例子)
变基的原理:临时保存一个分支的提交差异。 然后调整当前分支,最后再逐个应用差异。 参考: https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA
变基的应用场景: 像别人维护的项目贡献代码时
否则你的 ease 分支将会是很多分支合并的结果。包含了很多枝节。通过变基,则你只会推送上去一个线性的记录。管理者也方便进行查看应用你的修改。
(限于篇幅,还是考虑省掉了这个例子) git rebase –onto master server client 选中 在 client 分支上的修改,并且不在 server 做处的修改(c3) 基于master 变基。 注意这里的关键是 选中的修改 是 server 和 client 的差异。 参考:https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA
案例 :两个分支都修改了同一行代码。 然后进行变基操作。
.... 冲突(内容):合并冲突于 f1.py error: 无法合并变更。 打补丁失败于 0001 f1 444 失败的补丁文件副本位于:.git/rebase-apply/patch 当您解决了此问题后,执行 "git rebase --continue"。 注意之前先 git add . 如果您想跳过此补丁,则执行 "git rebase --skip"。 要恢复原分支并停止变基,执行 "git rebase --abort"。
变基应用领域,通常是为了给比人贡献代码的时候,整理代码用的。
原则:
变基的仓库只此一份,如果这个仓库有其他副本。比如有和其他人分享代码。那么不要进行变基操作。总的原则是,只对尚未推送或分享给别人的本地修改执行变基操作清理历史,从不对已推送至别处的提交执行变基操作,这样,你才能享受到两种方式带来的便利。(多人协作时将会造成混乱) 除非所有人都:git pull –rebase 如果已经有问题,这是缓解之道。但不能彻底解决问题。(不建议!)