对于小开发团队

Question

的Git分支策略我们有我们几乎每天更新和发布一个Web应用程序。我们使用git作为我们的VCS，而我们目前的分支策略非常简单和破坏：我们有一个主分支，并且检查我们对它感觉良好的更改。这个工作，但只有在我们检查一个突破性的变化。

没有人有小团队符合以下要求的最喜欢的Git分支策略：

1. 非常适用的2队3开发商
2. 重量轻，并没有过多的工艺
3. 允许开发者隔离的bug修复和更大功能的工作轻松
4. 使我们能够保持一个稳定的分支（对于那些“哦，废话”的时刻，当我们必须让我们的生产服务器的工作）

理想情况下，我很乐意看到你一步一步的过程，一个开发一个新的bug

Answer 1

你可能会受益于工作流程斯科特·查孔介绍Pro Git。在这个工作流程，你有两个分支始终存在，主和发展。

主人代表您的项目的最稳定的版本，你只能从这个分支部署到生产。

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

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

斯科特介绍了这些长期分支为代码“孤岛”，其中，在不太稳定的分支代码最终将“毕业”，以一个考虑了你的团队测试和一般的批准后更加稳定。

一步一步来，在这个模式下你的工作流程可能是这样的：

1. 你需要修复的bug。
2. 创建一个名为的分支myfix即基于开发分支。
3. 在这个话题分支的bug工作，直到它被固定。
4. 合并myfix进入开发。运行测试。
5. 你发现你的修复与另一个主题分支冲突hisfix你的同事合并到开发当你正在处理你的修复。
6. 在myfix分支中进行更多更改以处理这些冲突。
7. 合并myfix进入开发并再次运行测试。
8. 一切工作正常。合并发展到主。
9. 任何时候从掌握部署到生产，因为您知道它是稳定的。

有关此工作流程的更多详细信息，请参阅Pro Git中的Branching Workflows一章。

Answer 2

工作在VCS，只具有“主”分支快速地显示它的极限，因为你无法在一个分支上同时追求所有的开发工作。
这意味着你需要知道when to branch。

但在DVCS（如“分散式” VCS），你也有一个publication issue，用树枝您保持您的本地存储库，和树枝你是推或拉离。

在这种情况下，通过识别您的并行开发工作启动，并决定发布（推/拉）过程。例如（这不是唯一的方式）：

• prod是一个只读的公共分支与生产中的代码。每个人都可以从中拉以：
  • 重订其目前的发展在它的上面（用于本地测试，或在本地开发整合回购在督促回购做了督促分行修补程序）
  • 分支做新的功能（从一个已知的稳定代码）
  • 分支开始下一释放分公司（其中一个是要在生产）
    没有人应直接推到督促（因此只读）
• 释放是一个读写整合分支，其中relev蚂蚁承诺被挑选出来，成为下一个版本的一部分。
  每个人都可以推送发布来更新下一个版本。
  为了更新他/她的本地合并过程，每个人都可以从发布版本中获取。
• featureX是一个私人读写分支（因为它不需要推到中央prod回购），并且可以在dev回购之间推/拉。它代表中间的长期努力，从日常开发
• 主代表当前开发不同，推/ dev的回购之间拉出。

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

Answer 3

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

这非常适用于小型团队。这里的目标是确保所有可能不稳定的东西进入某种分支。当您准备好在功能部门之外工作的每个人使用它时，只需合并回主设备。

注意：这个策略几乎没有git特定，但git使得实现这个策略非常简单。

Answer 4

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

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

Answer 5

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

在开发窗口期间（直接提交或作为具有拉取请求的主题分支，由您决定 - 图中未显示），任何新功能都将继续使用master。完成所有计划功能后，输入功能冻结并执行测试。当你快乐时，将master上的发布标记为v1.0。

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

同时在master分支上可能会发生新的开发窗口，该分支最终会被标记为v1.1。

冲洗&重复。

这遵循Semantic Versioning编号逻辑。

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

Answer 6

（使我comment上面它自己的答案，因为我应该开始。）

从GitHub的斯科特·查孔：

我们如何做那么，什么是GitHub的流量？

• 凡是在主分支部署
• 上进行一些新的工作，创建一个描述性命名的分支关闭主（即： 新的oauth2-范围）
• 提交该分支机构本地，并定期把你的工作，以同样的命名分支的服务器上
• 当你需要反馈意见或帮助，或者您认为分支准备合并，打开一个 拉动请求
• 人后其他已审查并在 特征签了字，你可以把它合并到主
• 一旦合并，并推到“主人”，你可以而且应该立即部署

看到整个文章更多详细信息：http://scottchacon.com/2011/08/31/github-flow.html

需要注意的是“拉请求”是Github的发明，它的东西是烤到自己的网站，而不是Git的本身：https://help.github.com/articles/using-pull-requests/