欢迎使用CSDN-markdown编辑器

项目协作中避免版本混乱的方法

---

申明：本文仅适用于Git

---

很多情况下，我们出于不想折腾的想法，总是在master分支上提交代码，当然，如果我们不使用自动化部署并且以瀑布式开发的话，这种方法是极好的。但一旦我们需要以敏捷的方法进行项目开发的时候，大家都在master分支上提交代码就会引起混乱。经常发生的情况是：昨天测试还没有问题的，今天怎么就不行了？好吧，原来是修复一个bug的时候，把一段为新功能开发的代码也带进来了，而这段代码和旧的业务逻辑并不兼容。

这种情况会对测试人员造成非常大的困扰，都不知道自己测试的到底是个什么货色，也不知道什么时候才能把所有问题都回归一次。因为新的代码在不断地被提交上来，貌似永远也无法完成测试。。。

而让开发人员停止新功能的开发是不可能的事情。那么，要怎么做才可以排除这种干扰？一种有效的方法就是建立Git Workflow机制。SourceTree是一个免费的图形化Git管理工具，这个工具内建了对Git Workflow的支持。

点击【下载】进入官网下载。

开始新的项目

当我们在Gitlab上新建一个项目并Clone到本地的时候，先为项目建立脚手架，完成了这些准备工作并提交后，就应该开始进行Git Workflow的第一步：初始化Workflow参数。方法很简单，点击SourceTree工具栏的『Git 工作流』按钮，然后点击确定即可以默认的参数初始化。这个时候，当前工作分支会自动从master切换成develop。

现在，我们的版本分支情况是这样的：

开始开发第一个模块

现在，我们需要进行第一个功能模块的开发了，让我们先为这个功能建立一个专用的功能分支。再点一下SourceTree工具栏的『Git 工作流』按钮，这个时候，弹出的窗口和初始化就不一样了。我们点一下『建立新的功能』按钮，并且输入该功能模块的名称，选择开始于：最新的开发分支即可。然后点击确定，我们发现当前的分支已经自动切换到了刚才新建的功能分支上了。

这个时候的版本分支情况是这样的：

同时开始第二个模块的开发

一般情况下，我们不会同时只有一个功能模块在开发。其他同时进行开发的功能模块也需要独立的功能分支。操作和建立第一个功能分支没什么不同。

这个时候，总的版本分支情况是这样的（在别的功能分支没有拉取到本地的时候，本地是看不到的）：

完成第一个模块的开发

经过若干次的代码提交，终于完成了第一个功能模块的全部代码。这个时候，我们需要做一个完成功能的操作。点一下SourceTree工具栏的『Git 工作流』按钮，这个时候弹出的对话框又不一样了，我们只需要点击『完成当前版本』按钮，然后点击确定就可以了。这个时候，功能分支会被合并到开发分支上并删除，本地分支也会自动切换到开发分支develop。

这个时候，版本分支状况是这样的：

开始测试和准备发布第一个版本

到这里，如果可以发布版本的话，测试同学就可以上场了。我们的测试同学需要建立一个发布分支，点击SourceTree工具栏的『Git 工作流』按钮，再点击『建立新的发布版本』按钮，输入版本号，选择开始于：最新的开发分支，然后确定即可。这时候，测试同学的当前工作分支就会自动切换到新建的发布分支上。

这时候的版本分支情况是这样的：

对第一个版本的bug进行修复

很快，我们的测试同学就会提交一堆的bug，这个时候，开发同学就要暂时放下新功能模块的开发，把工作分支切换到发布分支上面来做bug的修复工作。

这个时候的版本分支情况是这样的：

完成第一个版本的测试并发布

现在终于修复了全部bug并进行了一次回归，并没有发现新的问题。是时候发布这个版本了。还是点击SourceTree工具栏的『Git 工作流』按钮，再点击『完成当前版本』按钮，然后点击确定按钮即可完成这个版本。SourceTree会自动把这个发布版本合并到master分支和develop分支并打上版本号的tag，然后删除这个发布分支。运维同学也就可以使用master分支构建并上线了。

这个时候，版本分支情况是这样的：

糟糕！线上有bug！！！

无论我们的测试同学有多努力，线上出现bug是司空见惯的事情。这个时候，只需要建立一个热修复分支，然后修复bug、测试通过再发布一次就好。老规矩，点击SourceTree工具栏的『Git 工作流』按钮，再点击『建立新的修复补丁』按钮，输入补丁版本号，然后点击确定按钮即可。这个时候，本地的工作分支会自动切换到hotfix分支上。在我们的开发同学修复了bug并提交代码后，测试同学进行验证通过后，就可以完成这次热修复。点击SourceTree工具栏的『Git 工作流』按钮，再点击『完成当前版本』按钮，然后点击确定按钮即可完成这个修复版本。SourceTree会自动把这个发布版本合并到master分支和develop分支并打上版本号的tag，然后删除这个热修复分支。运维同学也就可以使用master分支构建并上线修复了bug的版本了。

现在的版本分支情况是这样的：

开发更多的bug？

好吧，功能越多，bug越多。我们不断地修复线上的bug，不断地开发新的功能，版本号也越来越大。

我们的版本分支图会朝这样的趋势发展：但归根到底，永久性的分支只有两个：

• 主分支：master
• 开发分支：develop

在初始化Git Workflow后，任何人任何时候都不要在这两个分支上提交代码！！！

因为主分支是往生产环境发布的基础，而功能分支和发布分支都是以开发分支的最新版本为基准的。

最后，如何减少文件的版本冲突

在不同的分支上同时修改相同的文件才会造成版本冲突！

基于以上唯一真理，只要尽量避免在不同的版本中修改相同的文件，就能有效避免版本冲突。这就要求设计一个模块化程度很高的项目结构，不同的模块共同依赖的文件，在改动时先和大家打个招呼，小伙伴们不在同一时间修改，等你修改完及时合并修改就不会造成冲突了。