最佳（在您看来）GIT 工作流程，适用于按需发布（在大多数情况下一次 1-2 张工单）

Question

我是一个 Git 新手，正在寻求您的建议。

在我工作的公司中，我们有一个“工作流程”，我们的项目有一个 Git 存储库，有 2 个分支：master 和 prod。所有开发人员都在 master 分支上工作。如果票已完成（从开发人员的角度来看），我们将推送到 repo。如果所有测试都通过了，我们就会发布。

问题在于，在大多数情况下，业务人员的请求听起来像：“请释放票 A 或 A && B”。

在大多数情况下，我最终会做类似的事情

git checkout prod
git cherry-pick --no-commit commit_hash
git commit -m "blah blah to prod" -a

正如您所看到的，这不是一个完美的解决方案，而且我的印象非常深刻，这是一个完美的解决方案，尤其是当变更 A 依赖于变更 B 和 C 时。

如果更多开发人员在同一个分支上工作并且流程看起来像我上面描述的那样，您对如何处理按需发布有什么建议吗？欢迎所有建议。

我无法更改业务流程，它必须保持原样 - 很遗憾。

Answer 1

我们使用了像您这样的工作流程两年，最近放弃了它。我们发现了四个问题，每个问题都会随着您使用工作流程的时间越长而变得夸张。这是一个惊人的时间浪费，需要我们（诚然很小的）发布人员几乎全职的努力来管理。如果您还没有的话，这就是您几个月后要达到的目标：

1. 您的 master 和 prod 分支不共享提交历史记录，这意味着它们不能轻易地相互合并。这在您的此工作流程版本中尤其明显，因为您正在使用 --no-commit 标志进行挑选，然后重新提交文件。从某种意义上说，您是在同一组代码上维护两个不同的 git 存储库。在你点击之前，这听起来很容易管理......

2. 因为master 和prod 具有不同的历史，但prod 是master 更改的子集，您的分支会随着时间的推移而出现分歧。有时新功能会被废弃。有时业务人员会改变优先级。有时一个想法看起来很棒，直到你提交了 40 次并意识到它破坏了一切。将在master 分支中引入无法在prod 上重现的错误，其中一些将是根本看不到prod 的代码工件。如果没有持续的维护，master 的完整性就会降低。这很烦人，令人沮丧，并阻止真正的工作完成。更糟糕的是……

3. 您最终将修复 master 中不存在于 prod 中的合并冲突。当您将这些提交挑选到prod 时，您有很小的机会在挑选过程中引入错误。您的master 代码几乎是您的prod 代码，但微小的差异可能会产生意想不到的后果。如果您的开发人员不是特别注意空格或喜欢“实验”，那么问题就会被夸大。如果天才开发人员 Susie（他确实很聪明，但倾向于将遗留文件重构为更具可读性）检查一堆空白更改以及一两个合法的代码修复，那么您将把您的生产分支置于奇怪的灰色介于之前的状态和 master 上的状态之间。

4. 最后，如果将 -1-、-2- 和 -3- 组合在一起，就会遇到我们遇到的最严重问题：难以编写、测试和发布紧急修复程序和功能。当它发生危机时——你刚刚在你的应用程序中引入了一个安全漏洞； bizdev 刚刚签署了 MoneyBags McEnterprise 以获取一个中等国家的 GDP，他们所需要的只是 COB 提供的一套全新的工具——你需要修复 prod，因为这是必须的，但你不能。不容易。您所有的开发人员都在本地运行master。他们可以通过切换分支来运行prod，但是您的测试框架是硬连线到master 的代码的，它会阻塞prod 的所有新部分。没关系，你可以把它写在prod 上，然后再把它捡回master，对吧？嗯。并非没有遇到合并冲突和不同的文件。功能分支prod 并直接将其合并到master 怎么样？哦，是的，他们不分享历史……

可能是我们对这些问题的思考不够深入。我向你保证，那里的某个人对提交和历史记录足够小心以使这项工作顺利进行，你可能会在其他答案中听到他们的消息。尽管如此，这个工作流程在我们使用它的两年时间里浪费了大量的时间。我们围绕几个关键理念重新制定了我们的工作流程：

首先，git 中的分支既便宜又简单，因此我们将它们用于每个功能或案例。我们开发了一个命名方案，开发人员将特定案例的分支（我们的问题跟踪系统提供的案例编号）推送到一个可共享的地方。我们使用gitorious 为每个开发人员提供个人远程存储库，但您没有理由不能将这些“正在运行”的功能和案例推送到共享的origin。它需要一些组织和跟踪，但远低于上述问题所要求的。

其次，这些功能分支应该被切掉production，而不是master。除非某个功能或修复依赖于另一个“正在运行”的更改集，否则它应该基于显示问题或需要该功能的最上游分支。对我们来说，总是production。

第三，master，或者我们称之为主要开发集成分支的任何东西，只是在生产之上合并的“正在运行”功能分支的集合。它存在于集成测试和早期识别功能分支之间的合并冲突和依赖关系。它不是我们新代码的基础。我们在每个版本中重新设置它，并自动跟踪和合并“正在运行的主题”。我们还为 QA 部门维护了一个单独的 next 分支，该分支已停止生产，仅包含那些将在下一个版本中发布的功能分支。

这是我们改编自git project itself. 的工作流程，它是分布式的，对我们来说是一种范式转变。它可能对您有用，但如果没有，我仍然建议您寻求另一个工作流程。您当前的版本会随着时间的推移而退化，以至于您最终可能会像与代码抗争一样与版本控制抗争。

Answer 2

分支工作流的常见参考是A Successful Git Branching Model