我在一个拥有大型Java代码库（300k多行代码）的团队中工作，该团队最近采用Git作为源代码管理（从ClearCase迁移而来）。我们使用GitFlow作为我们的分支策略。有几个用例我们经常遇到，我们一直在努力解决。
-
我们已经将所有功能合并到开发分支中，以便在即将发布的版本中使用。当我们接近发布时，发现有一个功能无法上线（要么是由于客户端没有准备好，要么是其他原因）。创建发布分支的最佳方法是什么，但忽略了一个特定的功能（跨多个提交）？该功能需要可用，才能包含在下一个未来版本中。我们以前尝试过对所有提交执行"git revert"，创建发布分支，然后对已恢复的提交执行"git revert）"。这是一种非常痛苦的方法，尤其是对于大型功能。
-
我们已经创建了发布分支，但在发布生效之前，已经确定需要删除某个功能。与第一个用例类似，此功能需要能够进入下一个版本。正因为如此，仅仅对提交进行"git revert"并不能完全解决问题，因为当我们进行"git-flow release finish"时，revert将重新合并到开发分支中
正如GitFlow模型中所概述的，所有提交都是在功能分支上进行的，而不是直接在开发分支上进行。当一个特性完成并为下一个版本做好准备时，它就会被合并进行开发。到了下一个发布的时候，发布分支就从开发中创建出来了。在对该版本进行回归测试并在必要时进行修复后，它将进入生产并合并为master，在修复错误的情况下返回开发，并标记有版本号。当我们认为下一个版本中的一个功能最终需要省略时，就会出现上述问题。
处理这些情况的最佳方法是什么？在这两种情况下，分支都已被许多开发人员发布并删除，因此篡改历史可能会造成困难。我知道这些都不太理想，但不幸的是，情况已经超出了我们的控制范围。
在Git中，合并提交有两件事。首先，它创建了合并历史，这样Git就知道什么已经合并，什么还没有合并。其次，它将两条不同工作路线的变化结合在一起。
你可以在这两方面欺骗Git，这听起来就是你需要做的。有两种方法可以在不保留更改的情况下创建合并历史
git merge --strategy=ours
和
git merge
git revert -m 1 MERGE_SHA
前者创建一个合并提交（和合并历史记录），但忽略了通常会合并的所有更改。后者创建一个融合提交（和融合历史记录）并合并更改，但随后立即删除所有更改，同时保留第一个历史记录。
在您的例子中，如果您在中合并了一些内容，然后后来又改变了主意，那么您将希望使用第二种形式并恢复合并SHA。现在，为了防止合并中的更改传播到另一个分支，您需要使用第一种形式。请注意，为了有效地使用第一种格式，您可能必须一次合并一个SHA（或者仅为此使用一个附加功能分支）。
因此，假设您有一个包含6个提交（1-6）的分支trouble，您需要将trouble合并到master中，但不希望合并Commit 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
我一直在为同样的问题而挣扎。也许这里的关键在于不要使用git flow的"release finish"来防止反向合并到develop中。
想法是：
- 合并以照常开发
- 保持要素分支处于打开状态，直到它们合并到主控形状中
- 从上一个版本分支，并在准备下一个版本时合并要在其中发布的所有功能分支
- 在发布和开发分支上使用revert可以删除任何需要排除的功能
我也遇到了类似的问题。我能找到的最好的解决方案是实现"；特征切换（标志）"；以打开/关闭后续版本中的特定功能。您可以在开发中打开切换，在发布部署中关闭切换，如果您愿意，甚至可以在活动中打开/关闭切换。