Git的代码合进流程详解
总述
代码合进流程用于减轻代码合进复杂度、简化主分支历史（具有线性的历史）、保证合进代码对主分支的HEAD有效。
代码合进分为两步
- 解决冲突：将需要合进的分支变基到目标分支之上。保证合进代码对目标分支的HEAD有效。此时会解决所有代码冲突。
- 执行合进：向目标分支提交merge哀求，执行合进CI后完成合进。
其中第一步“解决冲突”的方法分为两种种情况：
- Squash。如 feature分支 向 dev分支 合进；存在冲突的合进。此时会出现 合进过程冲突多、合进结果复杂（commit多）、合进message不清楚（未能完整描述改动内容）的问题。此时不需要保存历史commit，仅需要干净的将feature合进master。
- Rebase。如 hotfix分支 向 dev分支 合进；feature分支 向 feature分支 合进。此时冲突少、合进结果简朴、需要保存历史commit。
其中第二步“执行合进”应采用 merge no-fast-forward 的方式。确保合进信息可追溯和易归退。
Rebase解决冲突
适用情况
- hotfix → develop
- feature → feature
- develop → master
其中commit数量少（1~2个），开发周期短（1day）。
操作方式
其中dev分支向master分支合进。通过执行 git log --all --graph --decorate 可观到如下图。两个分支已经分开，假如通过在master分支git merge合进且存在冲突，那么会触发三方合并在master生成merge commit污染主分支提交历史，这是我们不想观到的。
此时我们执行以下流程解决问题
git checkout dev && git pull dev git rebase master // 保证master与remote仓库一致 // 若发生冲突执行 git mergetool 解决冲突 git rebase --continue
此时可以观到master分支和dev分支干净得合在一起。经过单元测试并确认我们的改动没有bug后，我们可以push并开启mr。
Squash解决冲突
适用情况
- feature → develop
- gitlab → gerrit （此处为泊车自动同步代码中用到）
其中commit数量多（> 2个），开发周期长（> 1day），冲突量大（每个commit可能都有冲突）。
操作方式
此处仍旧是将dev合进master。其中dev分支提交历史混乱（有tmp提交），commit号多且每个commit都与master有冲突。此时在master分支执行 git merge dev 会触发三方合并，且保留不必要的commit历史。不必要的提交信息如图
操作的初始状态如图
此处我们执行如下操作，在master分支解决冲突并压缩提交。随后checkout一个提交分支并开启mr。这有利于简化主分支提交。但需要小心，dev分支不能再使用，需要重新从master分支拉取新的dev。
git checkout master // 保证master与remote一致 git merge --squash dev // 解决冲突 git mergetools 、 git commit -m <总结此次提交的所有内容> git checkout -b <mr-branch> git push xxxx
mater结果如图
Merge执行合进
这里强调使用merge no fast forward的目的是保留合进信息。
git checkout master git merge --no-ff dev
以上就是Git的代码合进流程详解的具体内容，更多关于Git代码合进流程的资料请关注其它相关文章！
