开发过程中如何解决代码版本冲突

一 概述

Git是一个非常好用的版本控制工具，在开发过程中我们利用它来进行版本控制，我们在开发的过程中会建立不同的分支来完成不同的功能。

• 主分支：master
• 开发分支：develop
• bug修复分支：hotfix
• 准备生产分支：realease
• 功能分支：feature

二 常见的代码版本冲突与解决方法

hotfix与devlop分支造成版本冲突

场景：当产品线上发现bug时，此时线上代码在master分支上，由于我们当前分支devlop时当前工作的分支，存在一些待测试验证的代码，所以我们需要从maseter分支中新拉出一个修复bug的分支命名为hotfix，当我们修复好bug时，会存在多种情况。

1. 当前修复的bug与devlop分支的代码同时上线。
2. 当前修复的bug早于devlop分支的代码上线。
3. 当前修复的bug代码晚于devlop分支的代码上线（一般不会如此）。

对于1解决方法：

我们可以从master分支再拉出一个新分支rebase，然后将bug和devlop同时合并到rebase分支上，最后解决冲突，当冲突解决后，代码变得稳定之后再合并到master分支上。

对于2解决方法：

由于bug分支的代码要提前上线，即提前被合并到master分支上，所以devlop分支的代码在提交前迟了一个版本，所以不能直接将其合并到master分支或者提交PR，我们应该先将master分支合并到devlop分支，然后解决掉版本之前的冲突，最后将稳定的且没有冲突的代码合并到master分支发布。

对于问题3的解决与2类似，但是这种情况一般不会出现。

多人协作开发造成的冲突

场景：多个人对于同一个版本master分支代码各自拉出一个新的分支进行开发，此时会存在多个人修改相同的内容，我们就不能直接提交代码，因为最后一个提交的人会将前几个人提交的代码覆盖。

解决方法：我们可以拉出一个共同的分支dev，此时当代码需要合并的时候，先提交到共同分支dev上，每个开发者提交代码之前都应该pull一下，在本地解决好冲突，然后发布代码到dev分支，当多人共同开发完后再将dev分支上稳定的代码合并到master分支上。