Temporarily remove feature from a Git branch

Question

We use git to manage our app's code repository, and have a situation that I have yet to encounter, but I imagine is very common.

We would like to temporarily remove a feature, and then add it back in at some point in the future. I am trying to imagine the branching structure that would support this, or if we should do something as simple as remove the feature from the code, and when ready to re-add it, re-create it from the commit history.

Can anyone point me in the right direction in terms of handling this situation?

Answer 1

One way you can temporarily remove your feature that predates your Git repo history is to make a commit that removes the feature. Then when you want to add the feature back in, simply revert the commit that took it out. This will do a reverse patch, meaning it will apply the changes in reverse, which will effectively re-add the feature:

git revert <sha of commit that removed the feature>

If you would like to make sure that you can easily re-add the feature later by keeping it in sync with changes to the code in the meantime, you can create a separate feature branch immediately after you remove it, and then just treat that branch like any other feature branch, and keep it in sync by frequently rebasing it against master (or a develop branch, if that's the way you want to do it), resolving conflicts as you go.

So basically, you would want to do something like this (it won't matter much if you're using a GitHub Flow or a Git Flow branching strategy, both use the concept of feature branches that eventually get merged into a main-line of development. For simplicity, I'll use GitHub Flow in this example):

# 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

Assuming you've kept saved-feature in sync frequently with master (or develop, if that's what you use), resolving conflicts as you go, you should have no problems merging the feature back in.

Documentation for reference:

• Rebase
• Revert
• Merge

Answer 2

This is a strategy that should work. It sounds like your work is pretty baked into your project, so here is what I would do. First select your starting point, for me usually dev branch (assuming there is also a master branch). Spin off the new branch that will be the feature removed from your project

git checkout -b dev_feature_removed

Also at the same time spin of a branch that will be that feature maintained in the project.

git checkout -b dev_feature_sustained

Now do the coding and testing you need to be sure that this feature is correctly and fully removed in dev_feature_removed and once you are sure that this is the case merge that branch back into production. In my case to dev for further testing and then into master to go live.

Meanwhile you can keep your other branch dev_feature_sustained also in your repo. You can merge dev into this branch to keep it synced and also add to your removed feature (bug fixes or new bells and whistles) for the day when it is returned to live by merging it back into dev (in my case probably master in your).

This return of the feature could cause merge conflicts depending on how tightly coupled your feature is. Since yours predates the repo it sounds like you'll be generating conflict no matter what because the merge strategies can only do so much. However, since you'll have two full commit trees, one with the feature and one without, you will know about the existence of every point where your feature reconnects to your project. So you'll have everything you need to place it back in your project. This is what I would draft up in my case. Good Luck, man.

Answer 3

Here's a concrete example showing the strategy in 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

Basically, restore-b always contains everything in prod plus the restoration of the feature (commit a122936). As you make new commits on prod, they are merged into restore-b, so that whenever you're ready to restore the feature, it's a simple fast-foward merge.

A simpler approach would be to avoid creating the a112936 commit and the restore-b branch until the point in time when you're ready to resurrect the feature. The advantage of creating and keeping up to date the restore-b branch is that any conflicts with other changes are resolved one by one, in a timely way (hopefully by the dev who wrote the conflicting code, soon after he wrote it). This keeps the feature "fresh" and "on-deck", ready to be included in a production release with no additional development work.

Answer 4

I’d solve this in the code itself. Add a feature map (which is basically boolean flags for each feature) and then just enable/disable features as needed without having to actually rip the code/logic from your repository.

Something in a configuration file as simple as:

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

And then in your corresponding controller:

<?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();
        }
    }
}

Note: Above is semi-pseudo code.