This topic created in 4779 days ago, the information mentioned may be changed or developed.
在用 Git 做版本控制的童鞋，可以聊聊你们如何管理 Git 分支吗？
一个持续开发的项目（APP、网站、软件都可），发布第一个版本后，我们面临着要相对固定周期迭代一个版本并对外发布，同时进行新功能开发和现有功能 Bug 的修复。
你们当计划要发布一个新版本时，是不是会建一个版本分支，然后这个版本发布的所有内容都是在这个分支里处理？
建这个版本分支前，假定所有新功能开发和 Bug 修复都是在一个开发分支（暂且叫 dev 吧）上往前走，这时如果有三个新功能在开发中、10 个 Bug 在修复中，但计划发布的版本只发布其中 2 个新功能、8 个 Bug 修复，那不是行不通吗？这个版本分支无法创建啊。
假定不用版本分支，而是每个新功能在开发时，创建一个功能分支，对于 Bug 修复也是如此。当计划下个版本要发布哪些功能时，将所在该版本要发布的功能的功能分支合并到开发主线，删除这些新功能分支，然后创建版本分支，然后直到发布，这个版本的事儿全部在这个版本分支里进行。
Supplement 1 · May 3, 2013
谢谢各位的回复，上午我们内部又讨论一番。得到的结果是：新功能和大的 Bug 都建临时性的分支，所有服务器端的分支管理由一个人严控，开发人员不能推送本地的分支到服务器上去。小的 Bug 或者极小的新功能直接在 dev 开发主线上处理。
准备发布一个版本时，创建以版本号为名的版本分支，确定了版本号后将相关的功能分支、Bug 分支合并，删除合并进来的临时性分支，这样可以减少同时在上面的分支数量。
版本发布后，版本分支并入 dev，dev 并到 master，并给 master tag 一个版本号。这时内部的版本分支则可以删除了。
我们准备试试这样的，看看效果。
11 replies • 1970-01-01 08:00:00 +08:00
 |
|
1
wwwjfy May 2, 2013  1
最后一段大致差不多。
除了一些神奇的需求，做完一个功能或 bug 都应该放到 master 里吧。某个版本直接打 tag 就行了，没什么只单独属于某个版本的提交
|
 |
|
2
davepkxxx May 2, 2013 1
Git在企业项目中的运作。
每个人都会从主项目中fork一个分支，开发完一个功能或者修复了一个bug就请求合并。
master是项目技术负责人专属，他会负责定期合并分支。
当然这个过程中少不了相互交流，建议用邮件形式。
|
 |
|
3
goinaction May 2, 2013 1
参考Gitlab的分支管理嘛，master分支始终保持稳定可发布，dev是开发主线，功能和bug修复再开其他分支，由项目管理人来细致的控制分支merge
|
 |
|
5
clino May 2, 2013 1
"但计划发布的版本只发布其中 2 个新功能、8 个 Bug 修复，那不是行不通吗？这个版本分支无法创建啊。"
可以在stable分支上cherry-pick dev分支上的patch
|
 |
|
7
jerommix May 2, 2013 via Android 1
gerrit.
|
 |
|
8
coagent May 3, 2013
@ davepkxxx 这样的流程，这里的“开发完”是不是指程序员写好代码并自己做了些测试，认为没问题了就请求合并么？中间是没有其他测试人员的。 |
|
|
9
coagent May 3, 2013
@ goinaction 我也觉得这样比较好，但内部不少人觉得每个功能和 bug 修复都创建一个分支会造成很多分支，后面要合并这些分支还会有很多冲突，觉得太复杂了。 |
 |
|
10
vietor May 3, 2013
"后面要合并这些分支还会有很多冲突，觉得太复杂了"，的确给人这样的感觉，只能逐步说服这部分人，这样的复杂带来的好处更多些。此外，新功能的增加和BUG修复不应该对原始结构进行大的改动，冲突没有想象的那么多。在实际开发过程中，我们的团队始终强调一句话“别对代码进行整体格式化”，就是避免因为类似“整体格式化”而产生的不必要却“很麻烦”的冲突。
|
|
|
11
davepkxxx May 3, 2013
@ coagent 是这个意思，测试不应该影响正常开发工作。项目开发到一定阶段就应该建立一个里程碑，然后让测试小组进行测试。 |
Select Language