让多个团队使用一个产品待办列表来开发一个产品,这些团队的每个成员经常将他们的代码提交到主干,而不是为每个团队设置分支是否是个好主意?
所以他们会在 Sprint 上单独工作,在代码审查后经常同步主干和他们的分支,然后首先将他们的工作代码添加到他们的分支中?
或者
我们可以使用什么方法,是否有任何标准模型?
让多个团队使用一个产品待办列表来开发一个产品,这些团队的每个成员经常将他们的代码提交到主干,而不是为每个团队设置分支是否是个好主意?
所以他们会在 Sprint 上单独工作,在代码审查后经常同步主干和他们的分支,然后首先将他们的工作代码添加到他们的分支中?
或者
我们可以使用什么方法,是否有任何标准模型?
Continuous Integration (to trunk) is a great state to aim for. A simple policy for branching is: Don't
I agree that sometimes you have no chance but to branch. In those circumstances, realize that when you do this, you are incurring a compound technical debt. The longer you leave the debt unpaid, the more it accumulates.
If you have to branch, do it as late as possible and merge back as early as possible.
频繁提交到主干可能会令人困惑,尤其是在频繁提交的情况下。一种方法是使用功能分支方法,其中一个功能在一个单独的分支中工作,直到它完成,然后它被合并到主干/主干中。这样,只有当您坚信某项功能有效时,您才会致力于掌握。如果此时主干/主干发生了变化,您可以简单地将其拉入功能分支并修复那里的任何冲突。
正如 Derek 所说,持续集成到 trunk/master 是一个努力的目标。可能只是您不希望在提交时出现很多混乱,例如“哎呀,忘记了那个配置”、“再试一次”、“快到了……”等评论。