我是一个 Git 新手，我正在寻求你的建议。
在我工作的公司中，我们有一个“工作流程”，其中我们的项目有一个 Git 存储库，有 2 个分支：master and prod。所有开发人员都致力于master分支。如果票证完成（从开发人员的角度来看），我们将推送到存储库。如果所有测试都通过了，我们就会发布版本。
问题是，在大多数情况下，业务人员的请求听起来像是：“请释放票据 A 或 A && B”。
在大多数情况下，我最终会做类似的事情
git checkout prod
git cherry-pick --no-commit commit_hash
git commit -m "blah blah to prod" -a
正如你所看到的，这不是一个完美的解决方案，而且给我留下了深刻的印象，这是一种完美的方法，尤其是当更改 A 取决于更改 B 和 C 时。
如果更多开发人员在同一分支上工作并且流程如我上面描述的那样，您对如何处理按需发布有什么建议吗？欢迎所有建议。
不幸的是，我无法改变业务流程，它必须保持原样。
我们使用像您这样的工作流程两年了，最近放弃了它。我们发现了它的四个问题，随着使用工作流程的时间越长，每个问题都会变得更加严重。这是对时间的极大浪费，需要我们（诚然规模很小）的发布人员几乎投入全部时间来进行管理。如果您还没有遇到过以下情况，那么几个月后您将遇到以下情况：
Your master and prod分支不共享提交历史记录，这意味着它们不能轻易地相互合并。这在您的工作流程版本中尤其明显，因为您正在挑选--no-commit标志，然后重新提交文件。从某种意义上说，您是在同一组代码上维护两个不同的 git 存储库。这听起来很容易处理，直到你击中......
Because master and prod有着不同的历史，但是prod是一个子集master的变化，你的分支会随着时间的推移而发散。有时新功能会被废弃。有时，业务人员会改变优先级。有时一个想法看起来很棒，直到你提交了 40 次并意识到它破坏了一切。错误将被引入master无法重现的分支prod，其中一些将是从未见过的代码产物prod根本不。如果没有持续的保养，master的完整性降低。这很烦人、令人沮丧，并且妨碍真正的工作完成。更糟...
您最终将解决合并冲突master不存在于prod。当你挑选这些提交时prod，在挑选过程中引入错误的可能性很小。你的master代码是almost your prod代码，但微小的差异可能会产生意想不到的后果。如果您的开发人员对空格不特别小心或不喜欢“实验”，那么问题就会被夸大。如果天才开发人员 Susie（她确实很聪明，但倾向于重构遗留文件以使其更具可读性）检查了一堆空白更改以及一两个合法的代码修复，那么您将把您的生产分支置于奇怪的灰色中说明之前的情况和现在的情况master.
最后，如果将 -1-、-2- 和 -3- 结合起来，就会遇到我们遇到的最严重的问题：很难编写、测试和发布紧急修复程序和功能。当出现危机时——您刚刚在应用程序中引入了安全漏洞； bizdev 刚刚与 MoneyBags McEnterprise 签署了一个中等规模国家的 GDP 项目，他们所需要的只是 COB 的一套全新工具 - 您需要修复prod因为那是必须起作用的，但你却做不到。不容易。你所有的开发人员都在运行master本地。他们可以跑prod通过切换分支，但您的测试框架是硬连线到master的代码，它会因为新的部分而窒息prod。没关系，直接写就可以了prod然后将其挑选回master， 正确的？嗯嗯。并非没有遇到合并冲突和分歧文件。功能分支怎么样prod并直接将其合并到master？哦，是的，他们没有共同的历史......
可能我们只是没有认真思考这些问题。我向你保证，有人对提交和历史记录足够仔细，以使这项工作顺利进行，你可能会在其他答案中听到他们的声音。尽管如此，这个工作流程在我们使用它的两年里浪费了很多时间。我们围绕几个关键想法重新制定了我们的工作流程：
首先，分行在git价格便宜且简单，因此我们将它们用于每种功能或案例。我们开发了一种命名方案，开发人员可以将特定于案例的分支（我们的问题跟踪系统提供的案例编号）推送到可共享的位置。我们用伟大的 http://gitorious.org/为每个开发人员提供个人远程存储库，但是您没有理由不能将这些“正在运行”的功能和案例推送到共享的origin。它需要一些组织和跟踪，但比上述问题所需的要少得多。
其次，这些特征分支应该被砍掉production, not master。除非某个功能或修复依赖于另一个“正在进行中”的更改集，否则它应该基于显示问题或需要该功能的最上游分支。对我们来说，永远都是这样production.
Third, master，或者我们所说的主要开发集成分支，只是合并在生产之上的“运行中”功能分支的集合。它的存在是为了集成测试，并尽早识别功能分支之间的合并冲突和依赖关系。它不是我们新代码的基础。我们在每次发布时都会重置它，并自动跟踪和合并“飞行中的主题”。我们还维护一个单独的nextQA 部门的分支，该分支已停止生产，仅包含那些将在下一个版本中发布的功能分支。
这是我们改编自的工作流程git 项目本身。 http://www.kernel.org/pub/software/scm/git/docs/v1.7.2.2/gitworkflows.html它是分布式的，对我们来说是一个范式转变。它可能适合您，但如果不适合您，我仍然建议您寻找其他工作流程。您当前的版本会随着时间的推移而退化，最终您可能会与版本控制作斗争，就像与代码作斗争一样。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
