代码合并过程用于降低代码合并的复杂度,简化主分支历史(带线性历史),保证合并后的代码对主分支负责人有效。代码集成分为两步。冲突解决:将要合并的分支的基础更改为目标分支。确保合并后的代码对目标分支的负责人有效。此时将解决所有代码冲突。壁球.比如feature分支合并到dev分支;存在整合的冲突。此时,合并过程中会出现许多冲突,合并结果复杂(多次提交),合并消息不明确(无法完整描述变更的内容)。此时,不需要保存历史提交,只需要将特征清理到主文件中。重定基数.如果热修复分支合并到开发分支;特征分支合并到特征分支中。此时冲突少,合并结果简单,需要保存历史提交。第二步“合并”应该采用合并不快进的方式。确保合并后的信息可以追溯并轻松回滚。

其中提交次数少(1~2),开发周期短(1天)。运行方式其中dev分支合并到master分支中。执行gitlog-all-graph-decorate可以看到下图。这两个分支已经分开了。如果它们在主分支中被git merge合并,发生冲突,就会触发三方合并在主分支中生成被merge commit污染的主分支的提交历史,这是我们不希望看到的。此时,我们执行以下过程来解决问题。git签出开发和git拉取开发Git rebase master //确保master与远程仓库一致//如果有冲突,执行git mergetool解决冲突。git rebase -继续复制代码此时,您可以看到master分支和dev分支净地结合在一起。在单元测试并确认我们的更改中没有bug之后,我们可以推送并打开MR。壁球解决冲突适用情况功能→开发Gitlab → gerrit(此处用于自动泊车同步代码)

其中提交数量多( 2),开发周期长( 1day),冲突数量多(每次提交都可能有冲突)。运行方式在这里,我们仍然将dev合并到master中。其中dev分支提交历史混乱(tmp提交),提交次数多,每次提交都和master冲突。此时,在主分支中执行git merge dev将触发三方合并,并保留不必要的提交历史。如图所示,在操作的初始状态中显示不必要的提交信息。这里,我们执行以下操作,解决主分支中的冲突并压缩提交。然后签出一个提交分支,打开Mr,这样有利于简化主分支的提交。但是要注意,dev分支不能再用了,需要再从master分支拉一个新的dev。Git checkout master //确保master与remote一致。git合并-挤压开发//解决冲突git mergetools,git commit -mgit checkout -bgit推送xxxx复制代码主要结果如图所示。Merge执行合并。这里要强调的是,使用merge no快进的目的是为了保留合并信息。git结账大师git合并-无-ff开发

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注