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修复不应该对原始结构进行大的改动,冲突没有想象的那么多。在实际开发过程中,我们的团队始终强调一句话“别对代码进行整体格式化”,就是避免因为类似“整体格式化”而产生的不必要却“很麻烦”的冲突。
|