小型开发团队的 Git 分支策略

我们有一个网络应用程序，我们更新和发布几乎每天。我们使用 git 作为我们的 VCS，我们当前的分支策略非常简单且不完善: 我们有一个主分支，我们检查我们“感觉良好”的更改。这个可以用，但只能在我们检查到一个重大改变之前。

是否有人有一个满足以下要求的 小分队 git 分支策略:

  1. 适用于2到3个开发人员的团队
  2. 轻量级，并且不需要太多的过程
  3. 允许开发人员轻松地隔离 bug 修复和更大特性的工作
  4. 允许我们保持一个稳定的分支(当我们必须让生产服务器工作的时候)

理想情况下，我希望看到您的一步一步的过程为开发人员工作的一个新的错误

97066 次浏览
小开

在 VCS 中，只有一个“主”分支很快就会显示出它的局限性，因为您不能同时在一个分支上执行所有的开发工作。
这意味着你需要知道 什么时候分支。

但是在 DVCS (如“ Decentralization”VCS)中，您还有一个 发布问题 ，其中包含保留在存储库中的本地分支，以及推送到或从中提取的分支。

在这种情况下，首先确定并发开发工作，然后决定发布(推/拉)流程。例如(这不是唯一的方法) :

  • Prod 是一个只读的公共分支，其代码在生产环境中:
    • 将其当前的开发基于它(用于本地测试，或者用于在本地 dev repo 上集成在 prod 分支上的 prod repo 中完成的修补程序)
    • 分支执行新特性(来自已知的稳定代码)
    • 分支启动下一个发布分支(即将进入生产环境的分支)
      没有人应该直接推送到 prod (因此是只读的)
  • Release 是一个读写合并分支，其中相关的提交被精心挑选出来作为下一个版本的一部分。
    每个人都可以推动发布来更新下一个版本。
    每个人都可以从上述版本中提取，以便更新他/她的本地整合流程。
  • Feature ureX 是一个私有的读写分支(因为它不需要被推送到中央产品回购) ，并且可以在开发回购之间被推送/拉取。它代表中长期的努力，不同于日常开发
  • Master 表示当前的 dev，并且在 dev repos 之间被推送/拉动。

其他版本管理过程也存在，比如这个 所以问题证明。

小开
最佳答案

您可能受益于 Scott Chacon 在 专业饭桶中描述的工作流。在这个工作流中，有两个始终存在的分支: 师父和 开发。

Master 代表项目的最稳定版本，并且您只能从这个分支部署到生产环境。

Development 包含正在进行的更改，这些更改可能不一定准备投入生产。

从 开发分支，您可以创建主题分支来处理各个特性和修复程序。一旦您的功能/修复准备就绪，您就可以将其合并到 开发中，此时您可以测试它如何与您的同事合并进来的其他主题分支进行交互。一旦 开发处于稳定状态，就将其合并到 师父中。从 师父部署到生产应该总是安全的。

Scott 将这些长时间运行的分支描述为代码的“竖井”，在这里，不太稳定的分支中的代码在经过测试并得到团队的普遍认可后，最终将“逐渐”升级为被认为更稳定的分支。

按照这个模型，您的工作流程可能是这样的:

  1. 你需要修正一个错误。
  2. 创建一个基于 开发分支的名为 我修好了的分支。
  3. 处理这个主题分支中的 bug，直到修复为止。
  4. 将 我修好了合并到 开发。运行测试。
  5. 您发现您的修复程序与另一个主题分支 他修好了发生冲突，您的同事在您修复程序时将这个分支合并到了 开发中。
  6. 在 我修好了分支中进行更多更改以处理这些冲突。
  7. 将 我修好了合并到 开发并再次运行测试。
  8. 一切正常。将 开发合并到 师父。
  9. 任何时候从 师父部署到生产，因为您知道它是稳定的。

关于这个工作流程的更多细节，请查看 Pro Git 中的 分支工作流章节。

小开

点击这里阅读 ReinH 为敏捷团队提供的 Git 工作流: http://ReinH.com/blog/2009/03/02/a-Git-working-for-Agile-team. html”rel = “ nofollow norefrer”> http://ReinH.com/blog/2009/03/02/a-Git-Workflow-for-Agile-teams.html

这对于小型团队非常有效。这里的目标是确保所有可能不稳定的东西都进入某种分支。只有当您准备好让特性分支之外的每个人都可以使用它时，才将其合并回 master。

注意: 这个策略几乎不是 git 特定的，但是 git 使得实现这个策略非常容易。

小开

作为一个新手，他试图找到一个直截了当的策略来教其他从未使用过源代码控制的开发人员。这是一个适合 http://nvie.com/posts/a-successful-git-branching-model/我尝试使用的标准 GIT 工作流程，在手册页，但它有点混淆我和我的观众完全。

在过去的6个月里，我只修复了两次冲突。 我已经添加了很多步骤，以便在开发特性时总是在合并后进行测试，以及“提取并合并”或“拉取——重建”(上午和下午各一次)。我们还使用 github.com 作为获取最新代码的中心站点。

小开

使用 master分支作为开发分支，并创建用于执行 bug 修复的发布分支。

在开发窗口期间，任何新特性都将在 master上运行(直接提交或作为带有 pull-request 的主题分支，由您决定——不以图形方式显示)。一旦实现了所有计划的特性，输入特性冻结并执行测试。当你高兴的时候，在 master上将发布标记为 v1.0。

随着时间的推移，用户会发现 v1.0中的 bug，所以您需要从这个标记创建一个分支(例如，以发行版 1.0的名字命名) ，并修复分支中的这些 bug。当你已经修复了足够多的错误，你认为它保证了一个新的发布，然后将其标记为 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
小开

(使我的 评论高于它自己的答案，因为我应该最初。)

来自 Github 的 Scott Chacon:

GitHub Flow 是什么？

  • 主分支中的任何内容都是可部署的
  • 要做一些新的工作，创建一个描述性命名的分支(即: New-oauth2-scope)
  • 在本地提交到该分支，并定期将您的工作推送到服务器上的同一命名分支
  • 当您需要反馈或帮助，或者您认为分支已经准备好进行合并时，请打开 拉请求
  • 在其他人审阅并签署了 功能，您可以将其合并到 master 中
  • 一旦它被合并并推到“ master”，您就可以并且应该立即部署

更多细节请参见整篇文章: 《 http://scottchacon.com/2011/08/31/github-flow.html 》

请注意，“ pull request”是 Github 的一个发明，它是一个嵌入到他们网站中的东西，而不是 Git 本身。 < a href = “ https://help. Github.com/article/using-pull-request/”rel = “ norefrer”> https://help.Github.com/articles/using-pull-requests/


提交答案