我是一个 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 时。
如果更多开发人员在同一个分支上工作并且流程看起来像我上面描述的那样，您对如何按需处理发布有什么建议吗？欢迎所有建议。
我无法更改业务流程，它必须保持原样 - 不幸的是。
我们使用了像您这样的工作流程两年，最近放弃了它。我们发现了四个问题，每个问题都会随着您使用工作流程的时间越长而变得夸张。这是一个惊人的时间浪费，需要我们（诚然很小的）发布人员几乎全职的努力来管理。如果你还没有的话，这就是你几个月后要达到的目标：
你master和prod分支不共享提交历史，这意味着它们不能轻易地相互合并。这在您的此工作流程版本中尤其明显，因为您正在挑选--no-commit标志，然后重新提交文件。从某种意义上说，您是在同一组代码上维护两个不同的 git 存储库。这听起来很容易管理，直到你击中......
因为master和prod有不同的历史，但是prod是master's 变化的一个子集，你的分支会随着时间的推移而发散。有时新功能会被废弃。有时业务人员会改变优先级。有时一个想法看起来很棒，直到你提交了 40 次并意识到它破坏了一切。将在master分支中引入无法在 上重现的错误prod，其中一些将是根本看不到的代码工件prod。没有持续的维护，它master的完整性就会降低。这很烦人，令人沮丧，并阻止真正的工作完成。更糟...
您最终将修复.master中不存在的合并冲突prod。当您将这些提交挑选到 时prod，您有很小的机会在挑选过程中引入错误。您的master代码几乎就是您的prod代码，但微小的差异可能会产生意想不到的后果。如果您的开发人员不是特别注意空格或喜欢“实验”，那么问题就会被夸大。如果天才开发人员 Susie（他确实很聪明，但倾向于将遗留文件重构为更具可读性）检查一堆空白更改以及一两个合法的代码修复，那么您将把您的生产分支置于奇怪的灰色介于之前和现在之间的状态master。
最后，如果将 -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 项目本身改编的工作流程。它是分布式的，对我们来说是一种范式转变。它可能对您有用，但如果没有，我仍然建议您寻求另一个工作流程。你当前的版本会随着时间的推移而退化，以至于你最终可能会像对抗代码一样对抗版本控制。
分支工作流的常见参考是一个成功的 Git 分支模型