我们有一个网络应用程序，几乎每天都会更新和发布。我们使用 git 作为我们的版本控制系统，我们当前的分支策略非常简单且不完善：我们有一个主分支，我们将我们“感觉良好”的更改检查到其中。这有效，但只有在我们签入重大更改之前才有效。
有没有人有最喜欢的 git 分支策略小团队满足以下要求：
- 非常适合 2 到 3 名开发人员的团队
- 轻量级，没有太多流程
- 允许开发人员轻松隔离错误修复和更大功能的工作
- 允许我们保持稳定的分支（对于那些我们必须让生产服务器正常工作的“糟糕”时刻）
理想情况下，我很乐意看到您为开发人员处理新错误的分步过程
您可能会受益于 Scott Chacon 中描述的工作流程Pro Git http://git-scm.com/book。在此工作流程中，您有两个始终存在的分支，master and develop.
master代表项目最稳定的版本，您只能从该分支部署到生产环境。
develop包含正在进行的更改，可能不一定已准备好用于生产。
来自develop分支，您可以创建主题分支来处理各个功能和修复。一旦您的功能/修复准备就绪，您就可以将其合并到develop，此时您可以测试它如何与您的同事合并的其他主题分支交互。一旦develop处于稳定状态，将其合并到master。从以下位置部署到生产环境应该始终是安全的master.
Scott 将这些长期运行的分支描述为代码“孤岛”，其中不太稳定的分支中的代码最终将“升级”到经过团队测试和普遍批准后被认为更稳定的分支。
一步一步地，您在此模型下的工作流程可能如下所示：
- 您需要修复一个错误。
- 创建一个名为myfix这是基于develop branch.
- 处理此主题分支中的错误，直到它被修复。
- Merge myfix into develop。运行测试。
- 您发现您的修复与另一个主题分支冲突hisfix你的同事并入develop当您进行修复时。
- 做出更多改变myfix部门来处理这些冲突。
- Merge myfix into develop并再次运行测试。
- 一切正常。合并develop into master.
- 部署到生产环境master任何时候，因为你知道它是稳定的。
有关此工作流程的更多详细信息，请查看分支工作流程 http://git-scm.com/book/en/Git-Branching-Branching-WorkflowsPro Git 中的章节。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
