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