问题描述
您可能会从 Scott Chacon 在Pro Git中描述的工作流程中受益。在此工作流程中，您有两个始终存在的分支， master 和 develop 。
master 代表您项目的最稳定版本，您只能从该分支部署到生产环境。
develop 包含正在进行的更改，可能不一定已准备好投入生产。
在 开发 分支中，您可以创建主题分支来处理单个功能和修复。一旦您的功能/修复准备就绪，您将其合并到 develop 中，此时您可以测试它如何与您的同事合并的其他主题分支进行交互。一旦 develop 处于稳定状态，将其合并到 master 。从 master 部署到生产环境应该始终是安全的。
Scott 将这些长期运行的分支描述为代码的“孤岛”，其中不太稳定的分支中的代码最终会在经过测试和团队的普遍批准后“升级”到被认为更稳定的分支。
一步一步，您在此模型下的工作流程可能如下所示：
- 你需要修复一个错误。
- 创建一个基于 开发分支的名为 myfix 的分支。 __
- 处理此主题分支中的错误，直到它被修复。
- 将 myfix 合并到 develop 中。运行测试。
- 您发现您的修复与您的同事在您进行修复时合并到 开发中的另一个主题分支 hisfix冲突。 __
- 在myfix 分支中进行更多更改以处理这些冲突。
- 将 myfix 合并到 开发 中并再次运行测试。
- 一切正常。合并 发展 为 大师 。
- 随时从master 部署到生产环境，因为您知道它是稳定的。
有关此工作流程的更多详细信息，请查看 Pro Git 中的分支工作流程章节。
解决方法
我们有一个几乎每天都会更新和发布的网络应用程序。我们使用 git 作为我们的 VCS，并且我们当前的分支策略非常简单且被破坏：我们有一个 master
分支，我们检查我们“感觉良好”的更改。这有效，但仅在我们签入重大更改之前。
有没有人喜欢满足以下要求的 小型团队的 git 分支策略：
- 适用于 2 到 3 名开发人员的团队
- 轻量级，没有太多的过程
- 允许开发人员轻松隔离错误修复和更大功能的工作
- 允许我们保持一个稳定的分支（当我们必须让我们的生产服务器工作时，那些“哦，废话”的时刻）
理想情况下，我很乐意看到您为开发人员处理新错误的分步过程