Git Flow中从版本中移除特性

Question

我在一个拥有大量Java代码（300k+行）的团队中工作，最近从ClearCase移植到Git作为源代码控制。我们使用Git Flow作为分支策略。我们经常遇到一些情况，一直在努力解决。

1. 我们将所有功能合并到develop分支中，以在即将发布的版本中使用。当我们接近发布时，发现某个功能不能上线（可能是由于客户没有准备好，或者其他原因）。创建发布分支的最佳方法，但要留出特定的功能（跨越多个提交）。该功能需要可以包含在下一个未来版本中。我们之前尝试过的方法是对所有提交执行"git revert"，创建发布分支，然后对恢复的提交执行"git revert"。这是一种相当痛苦的方法，特别是对于大型功能。

2. 我们已经创建了发布分支，但在发布上线之前，确定需要删除某个功能。与第一个用例类似，该功能需要能够进入以下版本。由于这个原因，仅对提交执行"git revert"并不能完全解决问题，因为还需要在"git flow release finish"时将撤销操作合并回develop分支。

正如Git Flow模型所述，所有提交都是在功能分支上进行的，而不是直接在develop分支上进行的。当功能完成并准备好进入下一个版本时，它会被合并到develop分支中。当需要发布下一个版本时，将从develop创建发布分支。发布经过回归测试并根据需要进行修复后，将进入生产环境并合并到master分支中，在进行错误修复的情况下还要合并回develop分支，并打上版本号。以上问题出现在我们认为可以在下一个版本中使用的功能最终需要被删除时。

如何处理这些情况是最佳方法？在这两种情况下，分支已经被许多开发人员发布和拉取，因此更改历史记录可能会带来困难。我知道这些情况不是理想的，但不幸的是我们无法控制。

- NickForrer

---

你可以避免直接在开发分支上提交代码，而是创建一个从最新发布版本开始的发布分支。这样你可以选择性地合并你想要加入到新版本中的功能。 - Sascha Wolf

@AndrewC 我已经更新了我的问题，并添加了一些额外的信息。 - NickForrer

@Zeeker 在 develop 分支上不直接进行提交。它们是从一个特性分支合并而来的。如果我们将特性合并到发布而不是开发中，仍然无法解决第二个用例。 - NickForrer

你有没有找到这个问题的更好解决方案？在我们剪切f1，完成更改并合并回开发时，情景变得非常糟糕。然后我们剪切f2，在f2上开始工作，f1被还原到开发分支上，当我们尝试将f2合并到开发分支时，它会将f1的更改再次合并回来。 - user797963

Answer 1

在Git中，合并提交有两个作用。首先，它创建合并历史记录，让Git知道什么已经合并，什么尚未合并。其次，它将来自两条不同工作线的更改合并在一起。

你可以在这两个方面都欺骗Git，这听起来就像是你需要做的事情。有两种方法可以创建合并历史记录，而不保留更改。

git merge --strategy=ours 

并且

git merge
git revert -m 1 MERGE_SHA

前者会创建一个合并提交（和合并历史记录），但不包括通常需要合并的所有更改。后者创建一个合并提交（和合并历史记录），并合并了更改，但随后立即删除所有更改，同时保留第一个历史记录。

在您的实例中，如果您合并了某些内容，然后改变主意，您将想要使用第二种形式并还原合并SHA。现在，为了防止来自该合并的更改向前传播到不同的分支，您将想要使用第一种形式。请注意，为了有效地使用第一种形式，您可能需要一次合并一个SHA（或使用仅用于此的其他功能分支）。

因此，假设您有一个包含6个提交（1-6）的分支“trouble”，您需要将“trouble”合并到主分支中，但您不想合并在提交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

- Andrew C

---

谢谢回复。当使用“git merge --strategy=ours”时，如果有我们想要合并的缺陷修复，但我们也不想合并还原提交，那么是否可能呢？ - NickForrer

我很好奇，当4准备好部署时，你们是如何合并它的？ - Erik Funkenbusch

@ErikFunkenbusch 我认为你需要使用 cherry / rebase -i / squash 分支来创建新的提交。 我会采取更简单的方法，在发布分支上撤销功能合并。在将其带回开发时，再次撤销。这样历史记录仍然是正确的线性。 但这实际上是git-flow的限制，它面向的是一个只有前向发布流程，这意味着现实中你需要在所有东西上都进行切换。如果开发流程需要按发布选择功能，则不要使用git flow，而是使用集成分支，并从功能构建每个发布分支。 - Tamir Daniely

这更像是主要的开源项目所做的事情，将功能保留在PR中直到它们准备好，并进行同步工作。如果该功能不值得保持同步，则可以进行回顾。 - Tamir Daniely

Answer 2

我们团队也面临着同样的问题。以下是我们的解决方案，稍微改变了gitflow的工作流程：

1. 从master分支创建发布分支
2. 从develop分支中挑选你想要的提交（即将发布的功能）
3. 按照gitflow工作流程，将发布分支合并到master和develop分支

- zeus2

Answer 3

我一直在苦恼同样的问题。也许关键在于不使用git-flow的“release finish”，以防止回溯合并到develop分支。

方法如下：

• 像往常一样合并到develop分支
• 保持功能分支开放状态，直到它们合并到主分支
• 从先前的发布分支中创建分支，并在准备下一次发布时将所有要发布的功能分支合并到其中
• 在发布和develop分支上使用还原，删除需要排除的任何功能

- user2329142

Answer 4

我曾经遇到过类似的问题。我找到的最佳解决方案是实现“功能开关（标志）”，以在后续版本中切换特定功能的开启/关闭状态。您可以在开发中打开开关，在发布部署中关闭它，甚至可以在运行时打开/关闭它，如果您愿意的话。

- user2343559