如何使用git执行每个任务策略的分支

Question

目前，我的团队正在寻找敏捷的git分支策略。我原本以为我们可以按照这篇文章：http://nvie.com/posts/a-successful-git-branching-model/，但不幸的是，我们常常推动生产，以至于无法在具有多个任务的分支上工作，直到它稳定（下一个发布分支策略）。此外，通常情况下，只需几天即可完成的问题需要一段时间才能解决，因为优先级变化。因为我们没有时间去处理这些长时间运行的任务，所以他们坐在开发者或下一个版本分支中，让位于打破生产的可能性。

我想采用每个任务分支策略，并想知道它如何使用git完成。我不只是在谈论功能分支，而是你分配的每个单独任务的分支。此外，由于您的任务分支将成为您的开发分支，因此不会有开发分支。拥有一个开发分支会促使开发人员直接致力于该分支，从而导致我们的主要分支开放问题。

我想出了这一点：http://imgh.us/ProtectedMasterBranch.jpg

我相信，采用该策略将保持主枝干净，也将占到开发商时不在身边来完成他们的任务，我们做一个推到生产前。

背后的主要思想是主分支是一个受保护的分支，没有开发分支。由于主分支受到保护，因此会强制您为单个任务创建分支。为了重新合并，您必须向管理员请求合并。我们将标记每个发布到生产中，并且修补程序也将从主分支中分支出来。我们有四个测试站点，可以用来测试不同的任务分支。

我还没有看到这个战略的任何例子，所以我希望得到一些反馈，我在这里有什么。

UPDATE

所以我知道它已经有一段时间，因为这个问题被张贴，但如果有人正在寻找类似的策略似乎是GitHub的已经通过了here。

在此先感谢。

Answer 1

你提到的git流模型是专门为解决你的问题而设计的:)。虽然它显示提交到develop，但所有任务都应在其自己的功能分支中完成，并且只有在完成并测试后才合并回develop。这样你就知道你总是可以从develop（即合并成主控和标签）发布，所以它支持定期和连续发布。

分支每任务工作真的很好，因为分支很便宜。我们也使用我们的问题编号作为前缀，因此git flow feature start PR-123_make-widget有一个可用的分支名称，但也突出显示了我们的JIRA中的PR-123问题。

遵循如上所述的git-flow方法可以为您提供一个稳定的开发分支（或者如果您正在开发一个主要的新版本分支以及develop，也可能有多个稳定的开发分支）修复后直接应用于master，然后合并回develop

对于您的'合并请求'，您可以使用pull请求（如果您使用的是Github，Stash，Bitbucket等），或者您可以使用像Gerrit这样的工具。

有一个合理的说法，其通过了所有测试应合并回任何分支自动发展，在这种情况下，你可以尝试每次提交的特性分支微评论做。有很多选择！

更新 如果你要坚持你的建议模型，我会建议考虑你的发布周期如何工作。该版本是否包含标记和推送，或者您是否冻结了一段时间以执行额外的质量检查？你以后可以这样做吗？如果答案是'是'或者'可能'，那么你不应该从主发布，而应该创建发布分支，执行最后一分钟的修复，然后标记和推送。不过，不要忘记重新合并。

更新 如果你正在使用它似乎会master分支没有实际意义的一个分支，每个任务的策略。如果您正在进行连续发布，那么每个稳定的开发分支构建都会自动部署到您的生产环境中，这可能是正确的。在将构建升级为生产的环境中，如果没有发布阶段，即升级不涉及任何其他提交，则可能不需要额外的分支。当你有一个释放阶段，其中最终发布的修补程序（部署问题，最后一分钟臭虫等）和一般看家develop/master分支策略的真正好处，如版本号凸点在瞬态release分支了。

使用发布分支，然后合并结果表明，到主分支意味着你可以继续合并稳定功能回到发展，即使你的版本尚未完成。

这也是相当不错的在主分支单提交点，每个代表提交的释放，但是这是一个纯粹的审美理由这样是不是真的那么有效:)。

Answer 2

我想通过每个任务战略的一个分支，想知道它是如何使用Git

Git的轻量级分支已与恰好考虑到这一点而专门设计，可以和最好之前已经完成应该为每个单独的主题创建分支。

以下是相当主观的。你指的是成功的分支模型是成功的，因为它的简单的常识（和调用它成功的营销世界保证分支和合并是不可怕的话）。我自己的证据是传闻，但按理说，大家谁与许多开发商有足够大的项目中使用混帐自然有发布，发展，阶段，featureX，featureY等分支机构，或它们的变体，它们之间具有共同的和标准化的流动。

你的流量，如图表所示，有道理，一只鞋不适合所有人 - 你不应该害怕在必要时偏离成功的git分支模型！

尽管如此，与每一个这种流动的主要问题是什么是你的分期，QA和发布策略。修复bug，开发功能，无论是在主题分支还是常见分支，都不是什么问题，代码就是代码。而git非常擅长在分支之间移动代码，将其分割为新的分支，倒回到代码的旧状态等等。

因此，您如何计划QA并发布代码？你有什么资源限制？ （构建时间，网络服务器，嵌入式线束，测试场，CI构建和测试盒等）就如一个例子，如果分支和移动代码很便宜，但建设或重建分支需要8个小时，每一个微小的变化分支是没有意义的。你的流程必须考虑这是一个成功的。