停止cherry-picking，开始合并，第11部分：VSTS团队的回应
原作者: Raymond Chen
原文链接: Stop merging if you need to cherry-pick: A response from the VSTS team
翻译日期: 2024年5月
VSTS团队写了一个回应，针对我几个月前发表的名为"停止cherry-picking，开始合并"的系列文章。
如果需要cherry-pick，就停止合并
作为Visual Studio Team Services的Git服务器的管理者，我们怀着极大的兴趣阅读了Raymond的"停止cherry-picking，开始合并"系列。当Raymond关注到你的领域时，你应该认真听取他的意见。看完这个系列后，我们对他的结论既同意又不同意。
考虑到Raymond团队工作的限制条件，我们认为他找到了一个相当不错的解决方案来解决一些非常实际的问题。由于历史原因，Windows有许多长期存在的分支，它们需要经常相互合并。如果你需要在官方集成计划之前，将一个修复从一个分支快速应用到另一个分支，你肯定会遇到Raymond所描述的那些冲突。
但是...如果你不是Windows，你可能没有这个问题。在VSTS，我们使用并推荐基于主干的开发模型，只有少数长期存在的分支。虽然我们的"发布流"模型确实包含一些发布版本的服务分支，但这些分支永远不会相互合并。因此，我们不会遇到Raymond团队所遇到的合并冲突和无声的工作回退问题。
在某种程度上，解决方案几乎和问题一样痛苦。你必须提前知道你将把提交cherry-pick到哪些分支。如果你不知道，你可能会把你的Git图搞得一团糟。而且如果你团队中的任何人不完全理解这种工作流所涉及的历史扭曲，他们可能会为你把一切都搞砸。由于这些原因，以及我们预计这在Windows工作流之外很少见，我们不打算在VSTS中添加任何功能来自动化这一过程。
另外需要注意：在任何情况下，在使用
git merge -s ours之前都要三思（甚至可能需要三思而后行）。虽然在这里它是正确的做法，但你是在故意丢弃别人的工作。我们处理过无数的客户工单，形式为"Git丢失了我的工作"。在绝大多数情况下，罪魁祸首是有人通过丢弃工作来解决合并冲突。Git没有丢失你的工作 — 你要求它忘记你的工作！感谢Raymond写了这个系列，并允许我们添砖加瓦。Windows团队一直是一个很好的合作伙伴，帮助我们让我们的服务器（实际上是整个Git）能够扩展到难以想象的规模和工作流。我们一直在考虑新的Git方法，这些方法可能适用于更广泛的社区。
我向VSTS团队表示感谢，感谢他们提供了他们的观点。
正如VSTS团队所指出的，问题出现在你对两个最终将会合并的分支之间进行cherry-pick操作的情况。如果这两个分支永远不会合并，那么你就不需要在cherry-pick时使用那些复杂的技巧。
