The current buzzword for feature flags is 'branch by abstraction'.

The idea is that instead of making a version control branch to change feature A to feature B and then merging back into the mainline of development, you build an abstraction over the thing you want to change, build a new implementation of that abstraction, switch out the two and then (if you like) remove the abstraction, all within the main line of development.

So instead of history that looks like this:

    *    Merge branch 'feature-cookie-login' into master
    |\
    | *  Polish up cookie feature
    | |
    . *  Switch from tokens to cookies
    . |
    . *  Clean up and refactor login code
    |/
    .
    .
    .

Your history looks like this:

    * Stop abstracting the authentication type.
    |
    * Switch from auth tokens to session cookies
    |
    * Add a SessionCookie authentication type.
    |
    * Start abstracting the authentication tokens as a generic authentication type
    |
    .
    .
    .

But with any completely arbitrary commits interspersed between those commits, as none of them break other code. The first one creates an interface, the second one reimplements the interface, the third switches the used implementation and the optional fourth removes the abstraction and deletes the old implementation.

Thanks.

The idea is usually to allow committing partially completed or deployed features, which are hidden by config flags until you're ready to activate them. When the feature is fully baked and effectively always on in production, you just remove the flag to make it permanent.

Using feature flags can increase a team's productivity by encouraging multiple commits a day, every day. It can also make rollbacks faster.

For my personal projects I often commit unfinished stuff. Using the kinds of flags you describe sounds like a good idea for projects where more people are involved indeed. Thanks.

well, it works for anything that you deploy often. some features are just big, and you don't want to have something sitting there undeployed for weeks. it helps to have bigger teams, because merging and deploying often is obviously good, but merging and deploying often help to make sure your individual parts don't slow anything down/etc, especially if the feature isn't self contained