Nic*_*rer 13 git version-control merge git-flow
我在一个拥有大型Java代码库(300k +代码行)的团队中工作,最近采用Git作为源代码控制(从ClearCase迁移).我们使用Git Flow作为我们的分支策略.有一些我们经常遇到的用例,我们一直在努力.
我们已将所有功能合并到开发分支中,以便在即将发布的版本中使用.当我们接近发布时,事实证明一个功能无法上线(由于客户端没有准备好,或者其他原因).创建发布分支的最佳方法是什么,但省略了一个特定功能(跨多个提交)？该功能需要包含在下一个版本中.我们之前尝试过的是在所有提交上执行"git revert",创建release分支,然后在恢复的提交上执行"git revert".这是一种非常痛苦的方法,特别是对于大型功能.
我们已经创建了发布分支,但在发布之前,确定需要删除一个功能.与第一个用例类似,此功能需要能够进入以下版本.因此,在提交中执行"git revert"并不能完全解决它,因为当我们执行"git flow release finish"时,恢复将返回合并到develop分支中.
如Git Flow模型中所述,所有提交都是在功能分支上进行的,而不是直接在开发分支上进行.当某个功能完成并准备好下一个版本时,它将被合并以进行开发.在下一个版本的时候,发布分支是由开发创建的.在对发布进行回归测试并在必要时进行修复之后,它将进入生产阶段并合并到master,然后在发生错误修复的情况下重新开发,并标记版本号.当我们认为在下一个版本中出现的功能最终需要被忽略时,上述问题就出现了.
处理这些情况的最佳方法是什么？在这两种情况下,分支机构已经被许多开发人员发布和删除,因此弄乱历史可能会造成困难.我知道这些不太理想,但不幸的是情况已经超出我们的控制范围.
在 Git 中，合并提交做了两件事。首先，它创建合并历史记录，因此 Git 知道哪些内容已合并，哪些内容尚未合并。其次，它将两个不同工作领域的变化结合在一起。
你可以在这两方面欺骗 Git，这听起来像是你需要做的。有两种方法可以创建合并历史记录而不保留更改
git merge --strategy=ours
和
git merge
git revert -m 1 MERGE_SHA
前者创建合并提交（和合并历史记录），但忽略通常合并的所有更改。后者创建合并提交（和合并历史记录）并合并更改，但随后立即删除所有更改同时保留第一个历史。
在您的实例中，如果您合并了某些内容，然后又改变了主意，您可能需要使用第二种形式并恢复合并 SHA。现在，为了防止合并中的更改向前传播到不同的分支，您需要使用第一种形式。请注意，为了有效地使用第一种形式，您可能必须一次合并一个 SHA（或为此使用附加功能分支）。
因此，假设您有一个trouble包含 6 个提交 (1-6) 的分支，并且您需要合并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