我在一个拥有大型Java代码库（300k +代码行）的团队中工作，最近采用Git作为源代码控制（从ClearCase迁移）。我们使用Git Flow作为我们的分支策略。我们经常遇到一些用例，我们一直在努力解决这些问题。
我们已将所有功能合并到开发分支中，以便在即将发布的版本中使用。当我们接近发布时，事实证明一个功能无法上线（由于客户端没有准备好，或者其他原因）。创建发布分支的最佳方法是什么，但省略了一个特定功能（跨多个提交）？该功能需要包含在下一个版本中。我们之前尝试过的是在所有提交上执行“git revert”，创建release分支，然后在恢复的提交上执行“git revert”。这是一种非常痛苦的方法，特别是对于大型功能。
我们已经创建了发布分支，但在发布之前，确定需要删除一个功能。与第一个用例类似，此功能需要能够进入以下版本。因此，只是在提交中执行“git revert”并不能完全解决它，因为当我们执行“git flow release finish”时，恢复将返回合并到develop分支中。
如Git Flow模型中所述，所有提交都是在功能分支上进行的，而不是直接在开发分支上进行。当某个功能完成并准备好下一个版本时，它将被合并以进行开发。在下一个版本的时候，发布分支是由开发创建的。在对发布进行回归测试并在必要时进行修复之后，它将进入生产阶段并合并到master，然后在发生错误修复的情况下重新开发，并标记版本号。当我们认为在下一个版本中出现的功能最终需要被忽略时，上述问题就出现了。
处理这些情况的最佳方法是什么？在这两种情况下，分支机构已经被许多开发人员发布和删除，因此弄乱历史可能会造成困难。我知道这些不太理想，但遗憾的是情况已经无法控制。
答案 0 :(得分：4)
在Git中，合并提交会做两件事。首先，它创建合并历史记录，因此Git知道已合并的内容和未合并的内容。其次，它将两个不同工作线的变化结合在一起。
你可以在这两个方面欺骗Git，这听起来像你需要做的。有两种方法可以在不保留更改的情况下创建合并历史记录
git merge --strategy=ours
和
git merge
git revert -m 1 MERGE_SHA
前者创建合并提交（和合并历史记录），但是省略了通常已合并的所有更改。后者创建合并提交（和合并历史记录）并合并更改，但随后立即删除所有的变化，同时保留第一个历史。
在您的实例中，如果您合并了某些内容然后稍后改变主意，您可能希望使用第二个表单并还原合并SHA。现在，为了保持从该合并的更改向前传播到另一个分支，您可能希望使用第一个表单。请注意，为了有效地使用第一个表单，您可能必须一次合并一个SHA（或者使用其他功能分支）。
假设您有一个包含6个提交（1-6）的分支trouble，您需要将trouble合并到master中，但您不想合并所引入的更改在提交4.而不是git merge trouble你会做
git merge 3 # merges 1/2/3
git merge -s ours 4 # creates merge history for 4, but does NOT merge any changes from 4
git merge trouble # merges 5/6
答案 1 :(得分：0)
我一直在努力解决同样的问题。也许这里的关键在于不使用git-flow的“发布完成”以防止向后合并到开发中。
想法是：
答案 2 :(得分：0)
我遇到了类似的问题。我能找到的最佳解决方案是实现“功能切换（标志）”以打开/关闭后续版本中的特定功能。如果您愿意，您可以在开发中打开和在发布部署中关闭，甚至可以在实时打开/关闭它。