git公共分支和个性化分支合并说明

合并命令：

git merge origin/develop 直接在当前分支合并远程分支代码到本地

git rebase origin/develop 使用变基的方式进行合并

以上两个命令都是可以的，但是使用rebase要注意会以远程develop分支提交记录为准。

从公共分支合并到个性化分支

场景描述：当我们开发在自己任务分支上开发的时候，组长在develop分支上合并完其它任务的代码，需要大家同步更新一下。

文件如下：

使用merge合并

组长在develop分支修改1.txt进行几次提交，并且推送到了远程分支

开发人员张三在本地库开发，修改了zhangsan.txt，只有一次自己的提交

此时张三在它的feature/zhangsan执行远程合并命令：

git featch：拉取远程最新变更信息

git merge origin/develop：执行合并，输入合并信息，也可以使用其默认的

这是最顺利的情况，没有任何冲突，直接就合并了。

解决冲突并合并

我们在develop分支，对文件zhangsan.txt进行修改，造成冲突，并提交，此时张三再执行合并。

可以看到，当我们按照流程输入了git merge origin/develop后，给出了提示：自动合并zhangsan.txt的时候存在冲突，请修复冲突然后提交结果。

并且我们可以看到最后，进行了MERGING模式，此时进入了合并模式，需要我们去解决冲突。

此时我们明确知道是zhangsan.txt文件参数了冲突，因此我们可以直接去看zhangsan .txt文件。 解决完冲突后：

当我们解决完后，重新提交即可：

可以看到解决完冲突后模式又进入了正常的工作区模式。

此时我们的提交记录就有两条，分别是组长提交和自己解决完冲突提交的，可以看到没有merge的信息了，那是因为当我们解决完冲突后的commit替换了自动合并commit信息。

使用rebase合并

在我们使用merge合并的时候，会要求给出一个merge信息，这是git在执行合并的时候需要记录一个合并的时间节点或者当前操作的记录，因此会生成一个merge记录。

我们的task分支（本地个性化分支）一般都是以公共分支为准，就是老大你说啥就是啥，我们都听你的，不自己搞小动作的情况下，我们可以使用rebase，通过变基的操作，以公共分支提交记录为准。

组长在develop分支修改1.txt进行几次提交，并且推送到了远程分支

开发人员张三使用rebase合并

git fetch

git rebase origin/develop

可以看到使用了rebase后，张三的分支所有记录都跟develop分支一样了。

解决冲突合并

我们在develop分支，对文件zhangsan.txt进行修改，造成冲突，并提交，此时张三再执行合并。

组长在zhangsan.txt中对内容修改，张三也对这个文件进行修改，组长进行提交。

张三也进行提交

张三使用rebase进行合并

可以看到，此时提示有冲突，需要解决冲突，并跟merge冲突出现的模式差不多，进入了REBASE模式。

此时我们手动解决冲突

继续合并，注意此时rebase模式下，继续合并不再是向merge使用提交进行合并了，因为对于rebase不会产生单独的合并提交，因此需要使用命令git rebase --continue

合并结果：

从个性化分支合并到公共分支

个性化分支合并到公共分支跟上面公共分支合并到个性化分支最大的区别在于，不要在使用rebase去合并个性分支。

对公共分支造成版本污染

因为个性化分支无法确定它在开发过程中是否还有合并其它个性化分支，或者它在本地操作的时候是否搞了很多骚操作，把整个版本树整得花里胡哨的，如果在公共分支上使用rebase去合并个性化，很可能导致公共分支的版本树变得不可控。

比如张三在开发过程中，需要李四的开发的一些工具包啥的，就直接跟李四商量，让李四提交代码到远程仓库，它去合并了，产生了一个合并记录。

此时develop再使用rebase也会产生这个记录

其实大多数时候公共分支只需要集成，不管你是怎么开发的，我甚至都不需要知道有李四这个人，这样就造成了公共分支出现了不可控的污染。

版本错乱追溯合并问题

更为严重的是，导致版本号丢失无法合并。

如在上图中

张三从B处进行checkout创建了分支feature/zhangsan

随后develop又提交了一个C

然后李四从C处checkout分支feature/lisi

张三开发完了，产生了提交KK

develop使用rebase合并张三KK

合并完的develop分支结果如下图所示

此时李四也开发完了并提交了TT

李四开始合并到develop，发现合并不进去了，因为C编程了C`，已经没有C了，虽然工作区文件内容是一样的，但是节点的id已经发了改变，这是因为rebase是采用的重放机制进行合并。

对于每个分支的独立视角来看，合并前是这样的：

张三看到自己分支有A、B、JJ、KK四个节点

组长看到develop分支有A、B、C三个节点

rebase合并的时候会找到两个分支最后一个公共节点进行重放，它们的公共节点就是B，然后将当前操作分支的commit会在rebase的目标分支上最后一个节点KK再重放执行一遍，重新执行一遍就导致此时的C节点不再是原来develop分支的C节点，会产生一个新的commit记录，它的id是不一样的。

这时候李四如果要追溯develop分支就追溯不到原来的C节点了。

加入develop开发完C后就提交到了远程长裤，此时再要将develop分支推送到远程仓库，就会推送不上去，只能加force参数强制推送，但是这种会由覆盖掉别人代码的风险。

综上述：一定不要在公共分支上使用rebase合并个性化分支，并且更不要在公共分支上使用force，会覆盖掉别人的代码，会被吊起来打的，老疼了