我宁愿一个Git新手，我期待你的建议。
在公司我为我们的工作有一个“工作流程”，我们有我们与2个分支项目的单个混帐回购协议： master和prod 。 所有开发者的工作master分支。 如果票（从开发的角度）来完成，我们推到回购。 如果所有的测试都通过了，我们做一个发布。
问题是，在大多数情况下，从业务人员的要求听起来像：“请释放票A或A && B”。
在大多数情况下，我最终会做这样的事情
git checkout prod
git cherry-pick --no-commit commit_hash
git commit -m "blah blah to prod" -a
正如你可以看到这是不是一个完美的解决方案，我下一个巨大的印象是，这是一个完美的方式无处特别是当改变依赖于改变B和C.
你有什么建议，如何处理按需版本中，如果更多的开发者工作在同一分支和流程看起来像我上面描述？ 所有建议都欢迎。
我不能改变业务流程和IT将不得不留，因为它是 - 很遗憾。
我们使用像你两年的工作流程和最近放弃它。 我们发现有问题吧，每个变得夸张的时间越长，你使用的工作流程。 这是时间的浪费惊人，需要由我们的（诚然小）释放人员近充分的时间精力来管理。 这里是你要什么在几个月打，如果你还没有：
你master和prod分支机构不同意提交历史，这意味着他们不能轻易合并到彼此。 这将是你这个工作流程的版本尤其明显，因为你是用樱桃采摘--no-commit标志，然后recommitting文件。 你是，在某种意义上，保持对同一套代码，两个不同的git仓库。 这听起来管理，直到你打...
由于master和prod有着不同的历史，但prod的一个子集master的变化，你的分支是发散的一段时间。 有时候，新功能得到报废。 有时候，业务人员会改变优先级。 有时候，直到你在40个提交和实现它打破了一切的想法似乎很大。 虫子会在推出master分支上没有的重复性prod ，其中一些将是代码工件，从来没有看到prod的。 如果没有持续的维护， master的完整性下降。 这很烦人的，令人沮丧，并防止实际工作中从得到完成。 更糟...
你最终会固定在合并冲突master不中不存在prod 。 当您樱桃采摘这些提交到prod ，你站在在樱桃采摘过程中引入错误的可能性很小。 你的master代码几乎是你prod代码，但小的差异可能会造成意想不到的后果。 问题是夸张，如果你的开发人员不特别小心空格或喜欢“实验”。 如果天才开发者苏西（谁真的是很光明的，但往往重构旧文件更可读）在一堆具有合法代码修复或两个沿空白改变的检查，你打算把你的生产分公司在一个奇怪的灰色与它以前和它是什么状态master 。
最后，如果你把-1-，-2，-3和你打，我们遇到的最严重的问题：这很难编写，测试和发布应急补丁和功能。 当它是一个危机 - 你刚刚推出应用程序中的安全漏洞; 业务开发部刚刚签署富翁McEnterprise一个中型国家的国内生产总值和所有他们需要的是的工具，通过COB一个全新的套装-你需要修复prod ，因为这是有工作的，但你不能。 不容易。 你所有的开发者正在运行master本地。 它们可以运行prod通过切换分支，但是你的测试框架是硬连接到master的代码，它是怎么回事各地的新部件呛prod 。 没关系，你可以把它写在prod和樱桃采摘回来交给master ，对不对？ Hmmmm。 不是没有击中合并冲突和分歧的文件。 如何功能分支prod ，只是它彻底融入master ？ 哦，是的，他们不共享的历史...
这是可能的，我们根本就没有想到够硬对这些问题。 有人在那里，我答应你，够小心的提交和历史，使这项工作，你可以从他们在其他的答案听到。 尽管如此，这个工作流程浪费的时间桶以上，我们用它两个yeras。 我们重新周围的几个关键概念我们的工作流程：
首先，在分支git是便宜和容易，所以我们使用他们的每一个功能或情况。 我们开发了一个命名方案，其中开发商推具体案件的分支（我们的问题跟踪系统提供的病例数），以一个共享的地方。 我们使用gitorious给每个开发者个人的远程存储库，但没有理由你不能推这些“飞行”的特点和案例共享origin 。 它需要一些组织和跟踪，但要少得多然后由上述问题所需要。
其次，这些功能分支机构应切断production ，不master 。 除非一个功能或修复依赖于另一个变化集是“飞行”，应该基于最上游分支，显示问题或需要该功能。 对我们来说，这总是production 。
三， master ，或任何我们调用我们的主要开发集成分支，是一个简单的“飞行”特性分支合并生产之上的集合。 它的存在对于集成测试和识别早期功能部门之间的合并冲突和依赖性。 这不是在我们立足新代码的东西。 我们与每一个版本重新设置它，自动化的“飞行中的主题”跟踪和合并。 我们还维护单独的next QA部门，这是切断生产和仅包含在下一版本中走出去的功能分支的分支。
这是我们从适应工作流程Git项目本身。 它的分布，相当我们的一个范式转变。 它可能为你工作，但如果没有，我还是会建议寻找另一个工作流。 您当前的人会随着时间的推移，到了那里你可能最终会为你战斗的战斗代码版本控制尽可能多的点。
分支流程一个共同的参考是一个成功的Git分支模型
