什么时候应该创建开发分支？

我们正在将我们的项目团队从使用单个Main / Trunk分支转移到应定期合并到Main中的多个Development / Work分支。我们将基于本文和《TFS分支指南》（我们正在使用TFS和Visual Studio 2010）建立新流程。

目前，任何时候都有1至5个人从事该项目。Main必须始终保持稳定，因为我们希望该选项可以在需要时释放。我们没有固定的冲刺-至少现在还没有-现在每1-2周发布一次。

现在，每个人都在修复整个应用程序中的错误。在几周内，我们将开始为该应用程序开发新的大型组件。

我们发现的一个症结是何时应该创建开发分支。我们将根据开发人员的技能水平并行实施多个用户故事。我们已经考虑过为每个开发人员创建一个分支，但这没有任何意义，因为在一件作品上总会需要一些协作。我们不能只靠一个开发分支，因为我们想在其他工作完成时合并到Main。

有人对此有指导吗？

我不喜欢任意分支，例如Fred的错误修正或Harry的错误修正。我对一个（独立）功能的一个分支更加满意，该分支允许多个开发人员对一项功能进行操作；但只有在功能完成时才能合并功能。

因此，现在您只需要“ bugfix”分支，但是一旦开始开发，就应该为每个重要功能创建一个分支。这样，完成后就可以合并并释放它们，而无需依赖其他错误功能。

不确定TFS在合并中的表现如何，但我相信您会在几个月后知道:)

我们不能只靠一个开发分支，因为我们想在其他工作完成时合并到Main。

听起来您已经知道必须创建多个开发分支。我想到了两种可能的情况：

1. 每5家开发商正在从事的项目（bug修复）的独立部分 -确保个人分支是为每个开发人员创建。这使每个开发人员都有责任和责任，以确保他们的更改集不会与其他任何人的工作冲突。您的五个开发人员之一很可能会犯错。如果是/在这种情况下，那么其他人受阻毫无意义。
2. 多个功能开发 -无论从事特定功能/错误的开发人员数量如何，都应将它们分开。一个有益的例子是，所有代码提交都是正在开发的功能的一部分-无需进行任何猜测。

DVCS的隐式工作分支

我们使用Mercurial，因此在开发人员dev框上有隐含的工作分支。提交总是完成到本地工作区。完成可发布的工作后，它将被推送到主回购服务器，并在其中自动构建和测试该服务器。

我们几乎从不创建显式分支，但是同样，我们的sprint不会超过1周，并且卡片的完成时间不超过1-2天。

而且，您可以通过将代码的其他部分或其他项目中的工作线程化来减轻合并的麻烦，因此人们不必一直进行困难的合并。

我使用了每个故事一个分支和每个发行版一个分支（所有开发人员都将他们的故事检入到dev中，如果其中任何一个破坏了dev分支，那么它对于所有人来说都是无效的）。如果您不喜欢冲突，我强烈建议每个故事一个分支。dev分支对于所有开发人员将始终保持稳定，并且开发人员无需等待其他开发人员已经破坏的代码段的等待时间。故事完成后，所有代码都在分支中。您将其合并到开发人员中，但不进行检入和测试，以防万一您遇到冲突时可以解决它，并要求与之冲突的人避免删除其代码。然后合并到开发人员。这有助于所有开发人员顺利工作。这也取决于公司的规模。我们公司有200名开发人员同时在一个代码库上工作，但他们的故事是分开的。将代码合并到dev分支后，立即删除Story分支。我希望这有帮助。谢谢

如果这是基于git的，则只需为每个错误修复程序创建一个分支，然后在最短的时间内修复该错误，将错误修复程序分支与开发分支合并，然后将更改推送到开发分支。审查请求请求和合并应该是最高优先级，因为完成得越快，合并不会引起问题的机会就越大。合并后，可以删除这些分支。