总述
代码合入流程用于减轻代码合入复杂度、简化主分支前史（具有线性的前史）、保证合入代码对主分支的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
