目前，我的团队正在寻找敏捷的git分支策略。我原本以为我们可以遵循这篇文章：http://nvie.com/posts/a-successful-git-branching-model/，但不幸的是我们过于频繁地投入到生产中，在其中有多个任务的分支上工作，直到它稳定（下一个版本分支策略）。此外，由于优先级的变化，通常情况下需要花费几天才能完成的问题需要一段时间才能解决。因为我们没有时间处理这些长期运行的任务，所以他们坐在dev或下一个发布分支中，让位于破坏生产的可能性。
我想采用每个任务分支策略，并想知道之前是如何使用git完成的。我不只是讨论功能分支，而是分配给您分配的每个任务。此外，由于您的任务分支将成为您的开发分支，因此不会有开发分支。拥有一个开发分支会诱使开发人员直接提交到该分支，从而导致我们的主分支中存在未解决的问题。
我想出了这个：http://imgh.us/ProtectedMasterBranch.jpg
我认为采用这种策略可以保持主分支的清洁，并且还可以解释开发人员在我们推动生产之前何时无法完成任务。
它背后的主要思想是主分支是受保护的分支，没有开发分支。由于主分支受到保护，它将强制您为单个任务创建一个分支。要合并回来，您必须从管理员请求合并。我们将每个版本标记为生产，并且修补程序也将成为主分支的分支。我们设置了四个测试站点，可用于测试不同的任务分支。
我还没有看到这个策略的任何例子，所以我希望得到一些关于我在这里的内容的反馈。
更新
所以我知道自从这个问题发布以来已经有一段时间了，但是如果有人在寻找类似的策略，那么GitHub似乎已经采用了它here。
提前致谢。
答案 0 :(得分：5)
您提到的git flow模型专门用于解决您的问题:)。虽然它显示了develop的提交，但所有任务都应该在他们自己的功能分支中完成，并且只有在完成并测试后才会合并回develop。这样你知道你总是可以从develop发布（即合并为主和标记），因此它支持定期和连续发布。
每个任务分支对git流程非常有效，因为分支很便宜。我们还使用我们的问题编号作为前缀，因此git flow feature start PR-123_make-widget具有可用的分支名称，但也突出了我们的JIRA中的问题PR-123。
遵循上面描述的git-flow方法为您提供了一个稳定的开发分支（如果您正在开发一个主要的新版本分支以及develop，那么可能会有多个稳定的开发分支。您也可以执行直接应用于master的热修复，然后合并回develop。
对于您的“合并请求”，您可以使用拉取请求（如果您使用的是Github，Stash，Bitbucket等），或者您可以使用像Gerrit这样的工具。
有一个合理的论点是，任何通过所有测试的分支都应该合并回来自动开发，在这种情况下，你可以尝试对特征分支进行按提交微观评论。有很多选择！
<强>更新 如果您要坚持使用建议的模型，我建议您考虑一下您的发布周期是如何工作的。该版本是否仅涉及标记和推送，或者您是否在一段时间内冻结以执行额外的QA？你将来可能会这样做吗？如果答案是'是'或'可能'，那么你不应该从master发布，而应该创建一个发布分支，执行你的最后一分钟修复，然后标记和推送。不要忘记合并回来。
<强>更新
如果您正在使用每个任务分支策略，那么master分支可能看起来没有任何实际意义。如果您正在进行持续发布，那么每个稳定的开发分支构建都会自动部署到您的生产环境中，这可能是真的。在构建被提升为生产而没有发布阶段的环境中，即促销不涉及任何额外提交，可能不需要额外的分支。 develop / master分支策略的真正好处来自于发布阶段，其中最终版本修复（部署问题，最后一分钟错误等）和一般内务管理（例如版本号颠簸）完成在一个短暂的release分支中。
使用发布分支然后将其合并到主分支意味着即使您的发布尚未完成，您仍可以继续将稳定功能合并到开发中。
在主分支上有单个提交点也很好，每个提交代表一个版本，但这只是一个纯粹的审美理由，因此并不真正有效：）。
答案 1 :(得分：1)
我想采用每个任务分支策略，并想知道在
之前如何使用git
Git轻量级分支是专门为此而设计的，您可以并且理想情况下应该为每个主题创建分支。
以下是非常主观的。您所指的成功的分支模型是成功的，因为它的普通常识（以及称之为成功的的市场营销，以向全世界保证分支和合并不会让人感到恐慌所有）。我自己的证据是轶事，但有理由认为，每个在很多开发人员的大型项目上使用git的人都会自然地发布， develop ， stage ， featureX ， featureY 等分支或其变体，它们之间具有公共和标准化的流。
你的流程，如图所示，是有道理的，而且一双鞋并不适合所有人 - 你不应该害怕在必要时偏离成功的git分支模型！
尽管如此，对于每一个这样的流程，主要的问题是你的升级，质量保证和发布策略是什么。修复错误，开发功能，无论是在主题分支还是公共分支上都不是问题，代码只是代码。并且git非常擅长在分支之间移动代码，将其拆分为新分支，重新绑定到代码的旧状态等。
所以更重要的是你如何计划QA并发布代码。您的资源限制是什么？ （构建时间，Web服务器，嵌入式线束，测试服务器场，CI构建和测试框等）作为示例，如果分支和移动代码很便宜，但构建或重新构建分支需要8个小时，那么每一个微小变化的分支都没有意义。你的流程必须考虑到这是一个成功的。
