Git 分支管理与版本发布的冲突问题

[coagent]

在用 Git 做版本控制的童鞋，可以聊聊你们如何管理 Git 分支吗？

一个持续开发的项目（APP、网站、软件都可），发布第一个版本后，我们面临着要相对固定周期迭代一个版本并对外发布，同时进行新功能开发和现有功能 Bug 的修复。

你们当计划要发布一个新版本时，是不是会建一个版本分支，然后这个版本发布的所有内容都是在这个分支里处理？

建这个版本分支前，假定所有新功能开发和 Bug 修复都是在一个开发分支（暂且叫 dev 吧）上往前走，这时如果有三个新功能在开发中、10 个 Bug 在修复中，但计划发布的版本只发布其中 2 个新功能、8 个 Bug 修复，那不是行不通吗？这个版本分支无法创建啊。

假定不用版本分支，而是每个新功能在开发时，创建一个功能分支，对于 Bug 修复也是如此。当计划下个版本要发布哪些功能时，将所在该版本要发布的功能的功能分支合并到开发主线，删除这些新功能分支，然后创建版本分支，然后直到发布，这个版本的事儿全部在这个版本分支里进行。

谢谢各位的回复，上午我们内部又讨论一番。得到的结果是：新功能和大的 Bug 都建临时性的分支，所有服务器端的分支管理由一个人严控，开发人员不能推送本地的分支到服务器上去。小的 Bug 或者极小的新功能直接在 dev 开发主线上处理。

准备发布一个版本时，创建以版本号为名的版本分支，确定了版本号后将相关的功能分支、Bug 分支合并，删除合并进来的临时性分支，这样可以减少同时在上面的分支数量。

版本发布后，版本分支并入 dev，dev 并到 master，并给 master tag 一个版本号。这时内部的版本分支则可以删除了。

我们准备试试这样的，看看效果。

[wwwjfy]

最后一段大致差不多。

除了一些神奇的需求，做完一个功能或 bug 都应该放到 master 里吧。某个版本直接打 tag 就行了，没什么只单独属于某个版本的提交

[davepkxxx]

Git在企业项目中的运作。
每个人都会从主项目中fork一个分支，开发完一个功能或者修复了一个bug就请求合并。
master是项目技术负责人专属，他会负责定期合并分支。
当然这个过程中少不了相互交流，建议用邮件形式。

[goinaction]

参考Gitlab的分支管理嘛，master分支始终保持稳定可发布，dev是开发主线，功能和bug修复再开其他分支，由项目管理人来细致的控制分支merge

[i0xbean]

git-flow

[clino]

"但计划发布的版本只发布其中 2 个新功能、8 个 Bug 修复，那不是行不通吗？这个版本分支无法创建啊。"
可以在stable分支上cherry-pick dev分支上的patch

[rrrrutdk]

http://nvie.com/posts/a-successful-git-branching-model/

[jerommix]

gerrit.

[coagent]

@davepkxxx 这样的流程，这里的“开发完”是不是指程序员写好代码并自己做了些测试，认为没问题了就请求合并么？中间是没有其他测试人员的。

[coagent]

@goinaction 我也觉得这样比较好，但内部不少人觉得每个功能和 bug 修复都创建一个分支会造成很多分支，后面要合并这些分支还会有很多冲突，觉得太复杂了。

[vietor]

"后面要合并这些分支还会有很多冲突，觉得太复杂了"，的确给人这样的感觉，只能逐步说服这部分人，这样的复杂带来的好处更多些。此外，新功能的增加和BUG修复不应该对原始结构进行大的改动，冲突没有想象的那么多。在实际开发过程中，我们的团队始终强调一句话“别对代码进行整体格式化”，就是避免因为类似“整体格式化”而产生的不必要却“很麻烦”的冲突。

[davepkxxx]

@coagent 是这个意思，测试不应该影响正常开发工作。项目开发到一定阶段就应该建立一个里程碑，然后让测试小组进行测试。