关于git的流程问题

Question

各位大神，小弟问一个流程问题
有一个master分支，一个dev分支，现在打算是这样子的，如果有一个新需求过来，则在master拉一条新功能分支进行开发，开发完成后合并到dev分支进行测试，如果没问题的话则直接把新功能分支合并到master上，我想问下这个流程是否有问题？如果有问题，问题出在哪？小白求教，大神勿喷

Answer 1

总得来说，具体的git工作流选择还是根据公司实际情况来说叭，也没有绝对的好坏，适合的才是最好的，所以如果你们现在这套工作起来感觉还不错，其实也就可以了

但是我可以提出自己感觉有可能有问题的地方，毕竟不在你们实际工作环境中，没准我提出的问题压根你们就不会出现，只是说这些问题假设出现的话，对你们现在的git工作流模式可能会有些影响

1. master分支稳定问题

master分支作为现网正在跑的代码分支，它的稳定程度会决定着系统运行的好坏，而对它的操作某种意义来说只有在经过测试后的代码要合并上线进行merge时才会用到master分支，可以说master最好是不要进行任何直接的commit和push操作，其他任何时候应该尽可能减少任何对于master分支的操作，包括从master分支上拉取新的分支这样的看似不会对master造成影响的操作，倒不是说不能从master分支上拉取，主要是新需求就拉取的话，这样的频率太高了，频率高，又是人工操作，大家熟悉程度又不一样，就很可能对master分支造成影响

假设你们团队每次需求开发都是从master上拉取一个功能分支大家一起在这个功能分支开发可能还好，因为只有一次拉取动作，leader去操作可能问题也不大，但是要是那种每个人都要单独拉一个个人分支作为功能分支开发，团队5个人，每个人自己去拉取属于自己的功能分支，那就不知道他们会对master分支做出什么可怕的操作了...

2. 新功能分支merge到master

这个操作看上去没问题，但是实际上有可能出大事，毕竟接受过测试的代码才可以merge到master，实际接受测试的是dev分支啊，dev分支包含了新功能分支，这样测试没问题，但不代表着经过测试了dev之后就可以把新功能分支merge到master分支上，这个还是有差别的

其实上面2个问题在以前我工作中也是遇到过的，所以当时我们公司最后采用了Gitflow的工作流模式，当然任何模式的学习会需要一些学习成本，所以实际是否运用到自己实际公司，还需要自行判断了，但是按照它给出的模式进行版本划分，确实可以解决大多数开发过程中的问题，就算不完全使用，也可以作为一些参考

在Gitflow工作流中，首先把代码分支分成几个部分

第一部分是主要部分，拥有无限生命周期的两个分支

• master
• develop

master当然就是我们线上的分支代码了，而develop是开发集成分支，这和题主的dev有些不一样，因为题主你的dev还包含了测试功能。

第二部分是辅助部分，他们生命周期有限，迟早是会被移除的

• feature
• release
• hotfix

feature代表功能开发分支，产品经理那边的需求
release代表发布分支，是测试人员进行测试的分支
hotfix代表现网bug分支
知道上面5个分支，现在连在一起说明一下它们各自的功能

1. 产品经理新需求来了

• 从develop分支拉取一个feature分支进行开发(这个时候可以团队成员可以自己去拉取自己的feature进行开发)
• 开发完成经过功能自测，合并feature到develop，删除对应feature
• 到测试时间，从develop分支拉取一个release分支，这个分支交给测试进行测试，测试完后，合并release到master和develop，然后删除release，如果期间测试有bug也在这个release分支上直接修改

2. 现网bug来了

• 从master分支拉取一个hotfix分支进行开发
• 开发完成经过功能自测，直接用hotfix分支进行提测，测试有bug直接在hotfix上修改，
• 修改完毕后，分别合并到master和develop，最后再删除hotfix
  

基本上上面两种流程可以包含了日常开发中大多数情况，并且也解决了上诉我提到的2个问题

当然这个明显有一些额外的学习成本，并且也要开发成员大家都认可并且执行这样的操作才行。
如果想要系统了解，可以参考gitflow作者原文《A successful Git branching model》

最后再介绍一个gitflow的插件吧，毕竟让人手动去执行各种的操作还是有可能执行错的，比如release需要分别merge到master和develop上（merge完了别忘了还要分别push），完了还要再删除release，这一套git操作下来还是要整死个人...

就是这个git flow intergration，看看这个安装量其实就说明针还不戳

怎么用，网上很多教程，我就不赘言了...

稀里哗啦就说了这么多了，主要以前这个问题，也是我们团队内大家积极思考的问题，当时也是大家群策群言吧，选择了gitflow，算是经验之谈，希望可以有帮到题主~( ^_^ )/~~拜拜

Answer 2

需求如果是单独的不划入此迭代的，或bug是线上bug，是可以直接从master上拉一条新分支进行feature 开发和测试 ，不需要合并到dev的，应该等到新分支稳定了，就可以分别合并到master，dev；

• 如果频繁的非此迭代的feature合并到dev（按楼主所说每次提交测试将会产生一个合并），也会打乱dev的节奏的；
• dev和master的版本相差太多，在dev上的测试未必在master上有效