什么是代码分支
在代码开发中，我们为了方便版本管理和开发、bug修复等工作，将代码分开不同的版本，开发人员使用不同的版本开发时，看到的文件可以完全不冲突，各自开发各自的功能。叫做不同的代码分支。
创建分支时总是在以前的分支基础上复制出来的
分支创建后，在新创建的分支上开发虽然不影响原来分支的代码，但并不意味着新分支的代码是凭空产生的，两者完全不搭边。新分支总是从旧分支中复制出来的，然后才在上面修改。我们当然可以将新分支的文件全部改成面目全非，但这样有意义吗？这样做这两个分支还怎么合并呢？所以，新分支与旧分支之间其实最终差异应该都不大。比如，新分支是用来开发一个小功能的，两个分支最终只有十几个文件发生了修改，合并起来也不会有太多的冲突。
开发人员应重视版本管理
上次大众创新奖的开发影响到立项的测试，就是因为我们一直没有重视版本和分支管理导致的。我认为我们应该吸取这次教训。相对规范的分支管理有助于我们更好的管理代码，甚至大家开发时可以互不影响，也方便测试。
创建分支的原则
那么，我们应该如何使用分支呢？我们应该用什么样的原则去创建和使用代码分支？
开发互不影响
创建分支是为了开发人员开发新功能时互不影响。这是最基本的原则。如果A和B两个开发各自正在开发不同的新功能，那么他们应该各自在本地创建出各自的分支，并在各自的分支上进行开发。那么，他们开发的中间各自是不会产生冲突文件的。
修改bug不需要创建专门的分支
有些开发人员可能会有疑问：难道改一个bug也要专门创建一个分支吗？我认为这大可不必，一方面，这太麻烦，也不是不可以；另一方面，分支是添加新功能时用到的，这不符合这个原则。
合并分支时，冲突应该是很少的
分支合并是分支管理最常用到的功能。如果没有合并，分支也就失去了意义。然而，合并分支一个麻烦事就是文件冲突了。两个分支同时修改了同一个文件的同一行，合并分支时就会发生文件冲突。然而，好的分支管理这种冲突应该是很少的，否则开发人员应仔细分析冲突代码后再合并。
生产环境版本上去后，应立即创建新的代码分支
原来的代码分支属于历史分支，可以用来进行代码历史版本备份。
我们的项目如何进行分支管理
以我们双创为例，我们应当如何进行分支管理呢？这里没有绝对正确的意见，我以我自己的角度，结合项目实际，谈谈自己的想法。
主分支保持跟生产环境代码一致
我们把生产环境目前的代码所在的分支称为主分支。只有生产环境进行版本变更时，主分支的代码才会发生改变。而且，开发人员一般不会直接修改主分支的代码，主分支代码的变更都是通过合并其他分支产生的。
创建一个bug修复分支，用来修改已发现的主分支上的bug
当生产环境版本发生变更后，我们马上创建一个新的分支作为主分支（原来的主分支作为历史分支，备份代码了，我们不会再修改它）。这时候主分支的代码跟目前生产环境的代码一致。现在，在主分支的基础上，我们又复制一个新的分支，称为bug修复分支。开发人员可以在这个bug修复分支上修复bug。
开发新功能
一般情况，开发人员需要同时开发新功能和修复旧版本bug的任务。修复bug的分支上面已经讲过了，那么，开发人员如何在开发新功能时，跟其他人的任务不发生冲突呢？最好的办法就是开发新功能时，在修复bug的分支基础上checkout出新功能的开发分支来（本地创建即可）。开发并自测完成后，再切到修复bug分支上，将新功能分支合并过来。这样，修复bug的分支bug被修复，同时新功能也不断被合并过来。
合并修复bug分支到主分支
开发人员在修复bug分支上产生多个beta版本供测试人员测试。当测试人员认为版本测试通过，可以打包到生产环境时，开发人员切到主分支，正式将修复bug分支合并到主分支。这时候主分支的代码应该会跟当前测试环境的代码一致（修复bug分支与主分支代码一致）。这时候，相当走完了一个生产环境版本变更流程，之后按照上述的方法进行版本管理即可。
hotfixs
最后，我们讨论一下hotfixs。hotfixs我们用得比较少，其实很多规范的项目都有这个概念和做法。
当版本上生产环境后，如果我们发现的影响很大的bug时，不可能又上一个新版本解决这个问题。这时候我们通常在主分支的基础上创建出一个hotfixs分支，然后在这个分支上紧急修复bug，然后将修改过的文件直接替换到生产环境（注意，不会重新打包）。替换完成后,再将hotfixs分支合并到主分支。这时候，主分支再一次跟生产环境保持一致了。
网友评论