小开发人员团队的Git分支策略[关闭]

我们有一个网络应用程序，几乎每天都会更新和发布。我们使用git作为我们的VCS，并且当前的分支策略非常简单且容易出错：我们有一个master分支，我们检查对它“感觉良好”的更改。这是可行的，但是直到我们签入重大更改为止。

是否有人对小型团队有喜欢的git分支策略，该策略满足以下要求：

1. 适用于2至3个开发人员的团队
2. 重量轻，过程不太多
3. 允许开发人员轻松隔离有关错误修复和较大功能的工作
4. 允许我们保持稳定的分支（对于那些必须使生产服务器正常工作的“糟糕”时刻）

理想情况下，我很乐意看到您针对开发新bug的开发人员的逐步过程

您可能会受益于Pro Git中描述的工作流Scott Chacon 。在此工作流程中，您始终有两个分支：master和development。

master代表项目的最稳定版本，并且您只能从该分支部署到生产中。

开发包含正在进行的变更，不一定准备好进行生产。

在develop分支中，您可以创建主题分支，以处理各个功能和修订。一旦功能/修复就绪，就可以将其合并到开发中，这时您可以测试它如何与您的同事合并的其他主题分支进行交互。一旦开发处于稳定状态，请将其合并到master中。从主服务器部署到生产环境应该总是安全的。

Scott将这些长期运行的分支描述为代码的“孤岛”，其中，不稳定的分支中的代码最终会在经过测试和团队总体认可后最终“升级”为被认为更稳定的分支。

逐步地，您在此模型下的工作流程可能如下所示：

1. 您需要修复错误。
2. 创建一个基于开发分支的名为myfix的分支。
3. 修复此主题分支中的错误，直到将其修复。
4. 将myfix合并到开发中。运行测试。
5. 你会发现另一个话题分支的修复冲突hisfix你的同事合并到开发的时候在你修复工作。
6. 在myfix分支中进行更多更改以处理这些冲突。
7. 将myfix合并到开发中并再次运行测试。
8. 一切正常。合并发展成大师。
9. 您可以随时从主服务器部署到生产环境，因为您知道它是稳定的。

有关此工作流程的更多详细信息，请查看Pro Git中的“ 分支工作流程”一章。

在以新手身份进入后，试图找到一种简单的策略来教其他从未使用过源代码控制的开发人员。这是一个适合http://nvie.com/posts/a-successful-git-branching-model/的模型，我尝试使用手册页中的标准GIT工作流程，但是这使我和观众完全感到困惑。

在过去的6个月中，我只需要解决两次冲突。我添加了一些步骤以在合并后始终进行测试，并在开发功能时进行很多操作（“每天早上和下午”“获取并合并”或“拉-重新设置”）。我们还使用github.com作为提取最新代码的中心位置。

（如我最初所说，在我的评论上方做出自己的评论。）

来自Github的Scott Chacon：

我们如何做，什么是GitHub Flow？

• master分支中的任何内容都是可部署的
• 要处理新的东西，请从master创建一个描述性命名的分支（即：new-oauth2-scopes）
• 本地提交到该分支，并定期将您的工作推送到服务器上的同一命名分支
• 当您需要反馈或帮助时，或者您认为分支可以合并时，请打开 拉取请求
• 在其他人查看并签署了该功能后，您可以将其合并到主功能中
• 合并并推送到“主服务器”后，您可以并且应该立即部署

有关更多详细信息，请参见整篇文章：http : //scottchacon.com/2011/08/31/github-flow.html

请注意，“拉取请求”是Github的发明，它已经融入了他们的网站，而不是Git本身：https : //help.github.com/articles/using-pull-requests/

将master分支用作开发分支，并创建用于执行错误修复的发行分支。

任何新功能都将master在开发窗口期间继续（直接提交或作为主题分支与拉动请求，由您决定-未在图形中显示）。实施所有计划的功能后，输入功能冻结并执行测试。满意时，将发布标记master为v1.0。

随着时间的流逝，您的用户会发现错误，v1.0因此您将希望从该标记创建分支（例如，在版本之后命名1.0），然后在分支中修复这些错误。修复了足够多的错误后，您认为它需要一个新版本，然后v1.0.1将其标记为并将其合并回master。

同时，master分支上可能会出现一个新的开发窗口，最终将其标记为v1.1。

冲洗并重复。

这遵循语义版本控制编号逻辑。

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

在VCS中，仅拥有一个“主”分支会很快显示其局限性，因为您不能在一个分支上同时进行所有开发工作。
这意味着您需要知道何时分支。

但是在DVCS中（例如在“分散式” VCS中），您还会遇到发布问题，其中分支位于本地存储库中，而分支正在推送或撤出。

在这种情况下，首先要确定并发的开发工作，然后确定发布（推/拉）过程。例如（这不是唯一的方法）：

• prod是一个只读公共分支，其代码正在生产中。每个人都可以摆脱它，以便：
  • 在其基础上重新构建当前的开发（用于本地测试，或用于在prod分支的prod repo中完成的修补程序集成到本地dev repo）
  • 分支以执行新功能（来自已知的稳定代码）
  • 分支以启动下一个发行分支（将在生产中的分支），
    任何人都不应直接推送到产品（因此为只读）
• release是一个读写合并分支，相关的提交被精心挑选为下一个版本的一部分。
  每个人都可以推送以更新下一个版本。
  每个人都可以退出该版本以更新其本地合并过程。
• featureX是一个私有的读写分支（无需将其推送到中央产品仓库），并且可以在dev仓库之间进行推送/拉取。它代表了中长期的努力，与日常开发不同
• master代表当前的开发者，并在开发者仓库之间被推/拉。

正如该SO问题所证明的，还存在其他发布管理过程。

在此处阅读ReinH的敏捷团队Git工作流程：http ://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

这对于小型团队非常有效。这里的目标是确保所有可能不稳定的内容都进入某种分支。仅当您准备好在功能分支之外工作的每个人都可以使用它时，才合并回master。

注意：此策略几乎不是特定于git的，但是git使实现此策略非常容易。