189

我们有一个几乎每天都会更新和发布的网络应用程序。我们使用 git 作为我们的 VCS，并且我们当前的分支策略非常简单且被破坏：我们有一个 master 分支，我们检查我们“感觉良好”的更改。这有效，但仅在我们签入重大更改之前。

有没有人喜欢满足以下要求的小型团队的 git 分支策略：

  1. 适用于 2 到 3 名开发人员的团队
  2. 轻量级，没有太多的过程
  3. 允许开发人员轻松隔离错误修复和更大功能的工作
  4. 允许我们保持一个稳定的分支（当我们必须让我们的生产服务器工作时，那些“哦，废话”的时刻）

理想情况下，我很乐意看到您为开发人员处理新错误的分步过程

4

6 回答 6

251

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

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

develop包含正在进行的更改，可能不一定已准备好投入生产。

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

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

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

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

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

于 2010-03-11T22:01:54.107 回答
46

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

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

于 2011-06-06T16:39:53.013 回答
35

（在它自己的答案上方发表我的评论，正如我最初应该做的那样。）

来自 Github 的 Scott Chacon：

我们是怎么做的，什么是 GitHub Flow？

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

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

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

于 2012-08-16T19:34:39.133 回答
15

将该master分支用作您的开发分支并创建发布分支以执行错误修复。

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

随着时间的推移，您的用户会发现其中的错误，v1.0因此您需要从该标签创建一个分支（例如，在 release 之后命名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
于 2011-08-26T20:15:11.177 回答
4

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

但是在 DVCS（如“去中心化”VCS 中）中，您也有一个发布问题，您将分支保留在存储库的本地，以及您要推入或拉出的分支。

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

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

正如这个SO 问题所证明的那样，还存在其他发布管理流程。

于 2010-03-11T21:58:09.863 回答
3

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

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

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

于 2010-03-12T14:53:56.357 回答