暂时从Git分支中删除功能

Question

我们使用git来管理我们应用程序的代码库，并且遇到了一个我尚未遇到的情况，但我想是非常常见的。

我们想临时删除一个功能，然后在将来的某个时候再添加它。我试图想象支持这一点的分支结构，或者如果我们应该做一些简单的操作，如从代码中移除功能，并准备好重新添加它，则从提交历史中重新创建它。

任何人都可以指出我处理这种情况的正确方向吗？

Answer 1

您可以临时删除您的Git repo历史记录之前的功能的一种方法是进行提交以删除该功能。然后，当您想要添加该功能时，只需简单地将revert the commit拿出来即可。这将做一个反向的补丁，这意味着它将适用于相反的变化，这将有效地重新添加功能：

git revert <sha of commit that removed the feature> 

如果你想确保你可以很容易地通过重新添加该功能保持它与代码更改同步，您可以在删除它之后立即创建一个单独的功能分支，然后像处理其他任何功能分支一样处理该分支，并通过频繁地将其与master（或者是一个develop分支，如果这是您想要的方式），随时解决冲突。因此，基本上，你会想要做这样的事情（如果你使用的是分支策略GitHub Flow或Git Flow，这两者都没有关系，它们都使用了特征分支的概念，这些特征分支最终被合并到一个主分支中， 。发展路线为简单起见，我将在这个例子中使用GitHub的流量）：

# On master branch 
git commit -m "Remove feature X" # Creates commit 1234567... 

# Now make feature branch 
git checkout -b saved-feature 

# Immediately put the feature back in the feature branch 
git revert 1234567 

# When you want to sync branch with master, just use rebase. 
# Rebase allows you to sync frequently, since it doesn't 
# leave behind a bunch of merge commits. 
# 
# From the feature branch: 
git rebase master # Resolve any conflicts as needed. 

# N commits later, you decide it's time to merge the feature 
# back in. You can use fast-forward or non-fast-forward merge, 
# it's up to you. 
# 
# Using fast-forward merge with master checked out (assuming 
# feature branch was just rebased onto master): 
git merge saved-feature 

# Or forcing a merge commit, if that's what you want: 
git merge --no-ff saved-feature 

假设你已经把saved-feature同步经常与master（或develop，如果这是你用什么），解决冲突，你走了，你应该没有问题合并功能回来。

文档以供参考：

• Rebase
• Revert
• Merge

Answer 2

这是一个应该工作的策略。这听起来像你的工作很融入你的项目，所以这就是我会做的。首先选择你的出发点，对我来说通常是dev分支（假设还有一个master branch）。关闭将从您的项目中删除的功能的新分支

git checkout -b dev_feature_removed 

同时旋转一个分支，该分支将在项目中保留该功能。

git checkout -b dev_feature_sustained 

现在做的编码和测试，你需要确保这个功能是正确和充分dev_feature_removed去除，一旦你确信是这样分支合并投产。在我的情况下，开发进一步测试，然后成为主人去住。

同时你可以让你的其他分支dev_feature_sustained也在你的回购。你可以合并dev到这个分支来保持它的同步，也可以添加到你删除的功能（错误修复或新的花里胡哨），当它返回到生活合并到开发（在我的情况下可能在你的主人）。

此功能的返回可能会导致合并冲突，具体取决于您的功能紧密耦合。由于您的回购早于您的回购，因此您无论如何都会产生冲突，因为合并策略只能做很多事情。但是，由于您将拥有两个完整的提交树，一个具有该功能，另一个不具有功能，您将知道功能重新连接到项目的每个点的存在。所以你会拥有一切你需要把它放回你的项目。这就是我要起草的案例。祝你好运，男人。

Answer 3

我会在代码本身解决这个问题。添加一个功能映射（这基本上是每个功能的布尔标志），然后根据需要启用/禁用功能，而不必实际从存储库中剥离代码/逻辑。

东西在配置文件一样简单：

<?php 
$features = array(
    'news' => true, 
    'events' => true, 
    'shop' => false 
); 

，然后在相应的控制器：

<?php 
class ShopController extends AbstractController { 

    public function __construct() { 
     // $features array would be passed in somehow; 
     // maybe via a dependency injection container 
     if (!$features['shop']) { 
      // feature is disabled, so just send 404 page for now 
      throw new ResourceNotFoundException(); 
     } 
    } 
} 

注：以上为半伪代码。

Answer 4

下面是John Galt's answer显示策略一个具体的例子：

$ git log --graph --decorate --oneline 
* d1d201b (HEAD, restore-b) Merge branch 'prod' into restore-b 
|\ 
| * 18d759f (prod) add feature e in prod 
* | 191037e Merge branch 'prod' into restore-b 
|\ \ 
| |/ 
| * e0de1be add feature d in production 
* | a122936 Revert "remove feature b in production" 
|/ 
* d3e2c42 remove feature b in production 
* 5369ecf existing three features 

基本上，restore-b总是包含在prod一切加功能的恢复（提交a122936）。当您在prod上进行新提交时，它们将合并到restore-b中，以便每当您准备好恢复该功能时，它都是一个简单的快速合并。

更简单的方法是避免创建a112936提交和restore-b分支，直到您准备好重新生成该功能为止。创建并保持最新的restore-b分支的优势在于，与其他更改的任何冲突都能够及时解决（希望在编写冲突代码后不久，他就可以写出它）。这保持了“新鲜”和“在甲板上”的功能，随时可以包含在产品发布中，而无需额外的开发工作。