我最近一直在研究 git 工作流程,哪个最适合我们的团队。
我们可以使用的最好(或最好的)git 工作流程是什么?此工作流程应尊重以下部分/大部分/所有要点:
- 2 个团队将使用 git(每个大约 8 人),他们都在同一个应用程序上工作。每个团队可能有也可能没有自己的私有存储库。
- 该应用程序有多个版本。版本(n+1)的开发开始可能在版本(n)发布之前开始。版本 (n+1) 上的开发不应包含在版本 (n) 中
- 客户可能会在最后一刻决定不将 Feature x 包含在前一个月开发的下一个版本中。
- 项目历史应该很容易理解。
我的工作流程理念:与可在此处找到的工作流程略有不同: http: //nvie.com/posts/a-successful-git-branching-model/
- 两个团队的一个中央存储库,可通过 SSH 使用。
- 分行主稳定。
- 没有创建分支开发。相反,应用程序的每个版本都有自己的分支,团队在这些分支上进行开发。版本 (n+1) 的分支是从版本 (n) 的分支创建的。因此,分支 (n+1) 上可能会出现新的开发人员,而分支 (n) 上可能会出现错误修复。
- 为每个新功能和错误修复创建一个分支,就像在模型中一样。
- 两个团队只有一个中央存储库,因为为每个团队使用两个主要存储库似乎并不容易。每个团队有两个存储库的工作流程是什么?值得吗?
- 大多数(如果不是全部)合并不应该快进,因为如果发生快进,似乎没有办法阻止 Feature x 被包含在内。
- 发布时,将版本 (n) 合并到 master 中,并标记
另外,这样的策略不会有太多的分支吗?发布后很容易有大约 30~ 个错误修复。如果每个 bug 修复都建立分支,那么很快就会有很多分支。有什么办法可以避免这种情况吗?
补丁工作流程是个好主意吗?会是什么呢?我认为每个错误修复和功能都可以有自己的补丁,让客户能够选择他想要的补丁。
感谢您的帮助。