Question

我们有一个我们几乎每天更新和发布的网络应用程序。我们使用git作为我们的VCS，我们当前的分支策略非常简单和破坏：我们有一个主分支，我们检查我们感觉良好的变化。这是有效的，但只有在我们检查一个重大变化之前。

是否有人对小型团队最喜欢的git分支策略符合以下要求：

适合2至3名开发人员的团队
轻量级，而不是太多的过程
允许开发人员轻松隔离错误修复和更大功能的工作
允许我们保持稳定的分支（当我们必须让我们的生产服务器工作时，那些“糟糕的”时刻）

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

Answer 1

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

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

develop 包含正在进行的更改，可能未必为生产做好准备。

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

斯科特将这些长期运行的分支机构描述为代码的“孤岛”，其中一个不太稳定的分支中的代码最终将“毕业”为经过测试并得到团队一般批准后更稳定的代码。

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

您需要修复错误。
创建一个名为 myfix 的分支，该分支基于 develop 分支。
处理此主题分支中的错误，直到修复为止。
将 myfix 合并到 develop 中。运行测试。
您发现修复与另一个主题分支 hisfix 冲突时，您的同事在您修复工作时合并到 develop 。
在 myfix 分支中进行更多更改以处理这些冲突。
将 myfix 合并到 develop 并再次运行测试。
一切正常。将 develop 合并到 master 。
随时从 master 部署到生产环境，因为您知道它是稳定的。

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

Answer 2

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

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

Answer 3

（让我的comment高于它自己的答案，就像我最初应该的那样。）

来自Github的Scott Chacon：

我们如何做到这一点，什么是GitHub Flow？


主分支中的任何内容都是可部署的

要处理新事物，请从master创建一个描述性命名的分支（即：   new-oauth2-scopes）

在本地提交该分支，并定期将您的工作推送到服务器上的同一个命名分支

当您需要反馈或帮助时，或者您认为分支已准备好进行合并时，请打开一个   拉取请求

其他人审核并签字后   功能，您可以将其合并到主

一旦合并并推送到'master'，您就可以并且应该立即部署

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

请注意，“拉取请求”是Github的发明，而且它是在他们的网站上出现的，而不是Git本身：https://help.github.com/articles/using-pull-requests/

Answer 4

使用master分支作为开发分支，并创建发布分支以执行错误修复。

任何新功能都会在开发窗口期间继续master（直接提交或作为带有请求的主题分支，由您决定 - 未在图中显示）。完成所有计划的功能后，输入功能冻结并执行测试。如果您满意，请将master上的版本标记为v1.0。

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

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

冲洗＆amp;重复。

这遵循Semantic Versioning编号逻辑。

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

Answer 5

在VCS中，只有一个“主”分支快速显示其限制，因为您无法在一个分支上同时进行所有开发工作。
这意味着您需要知道 when to branch 。

但是在DVCS中（如“分散式”VCS），您还有一个 publication issue ，您的存储库可以保留本地分支，以及您要推送或拉动的分支机构从

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

prod是一个只读的公共分支，代码正在生产中。每个人都可以从中拉出来以便：
- 在其上重新定义其当前开发（用于本地测试，或在本地dev repo上集成在prod分支上的prod repo中完成的修补程序）
- 分支执行新功能（来自已知的稳定代码）
- 分支启动下一个发布分支（即将生产的分支）
  没有人应该直接推销（因此是只读的）
release是一个读写合并分支，其中相关提交被选为下一个版本的一部分。
每个人都可以推出发布以更新下一个版本每个人都可以从上述版本中获取，以便更新他/她的本地整合过程。
featureX是一个私有读写分支（因为它不需要推送到中央prod repo），并且可以在dev repos之间推/拉。它代表中长期努力，不同于每日开发
master表示当前dev，并在dev repos之间推/拉。

存在其他版本管理流程，如SO question attests。

Answer 6

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

这适用于小型团队。这里的目标是确保可能存在潜在不稳定性的一切都进入某种分支。只有当你准备好在功能分支之外工作的每个人使用它时，才能合并回主人。

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

小开发团队的Git分支策略

6 个答案: