Git分支变基

最近上级要求弄一个Git的使用说明，并且重点要说一下分支的处理。我尽管也在使用Git管理代码等，但分支这块还真没有真正去深究过，今天去查官网的资料，发现 官网的那说明有点前后矛盾，越看越糊涂，自己简单说下自己的理解。

官网解释

分支变基的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行变基的分支 experiment）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 master）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3’），从而改写 experiment 的提交历史，使它成为 master 分支的直接下游。


前面一个变基后是测试分支的副本，且是直接合并到主分支后面；后面的协同处理时变基产生的是根存档的下一级，直接取代以前的根存档C1的下一个存档C4。我验证出来应该第二张图的才是正确的。

自己的理解

借官方的图来说吧，在代码仓库里有源存档C1，有主程序员A和程序员B，主程序员A修改代码后存档C4，程序员B新建分支修改代码后存档为C5，与主程序员A的存档合并为存档C6，后来通过会议确定C4里的功能完全用不到，为了不给后面的人造成干扰，此时程序员B就在自己的分支处与元存档C1合并 并 进行 变基 操作，就产生存档C4’，此存档将取代原来存档C4在主存档中的位置（原来的主分支C4及其后续存档将独立出去），而且C4’直接继承原来主分支上C4的提交人和提交说明信息,如果在你变基的同时有人以C4为基础编了新的程序，在你变基后他又将程序上传上去了，那到时候远程仓库中将出现两个不同的存档C4的记录，有着不同的 SHA-1 校验值，却拥有相同的作者日期与说明。因此，一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行变基操作

仅是自己的一点初浅见解，如有错误，欢迎指出，谢谢！