Why I don't like Gitflow?

While Iām sure it can probably be useful in certain situations, I donāt like Gitflow and the ideas behind it. I think itās way too complex and that there are other easier solutions for a smoother workflow.
Gitflow is a branching strategy that allows to split the development of a project by building features
on isolated branches
.
The idea is to checkout a branch everytime the development of a new feature starts.
When the feature looks finished, the feature branch is merged on a develop
branch which generally represents a specific - and entire - environment where the different features crosses and can be played altogether by anybody having access to the environment.
When itās time to release a specific feature, a new release
branch is checkout. QA folks are doing their best to verify the behaviour of the different features that have to be shipped and provide feeback to the dev team.
The developers are supposed to only make hotfix
commits on these branches by checkout some hotfix
branches and merge them directly inside the release branch.
When everything looks good, the hotfix
branch is merged back to develop
so that it benefits from the different hotfixes and also in the master
branch which is the āproductionā branch.
Itās like a 5 tracks race.
My main concern about Gitflow is complexity.
From my perspectives, people using Gitflow are trying to solve these problems ahead of time and in their development environment. They are trying to solve these problems at the git
level.
But the thing is itās not a git
problem. We donāt have to solve it only using git.
Instead of having a 5 tracks situation, letās imagine a 2 tracks scenario where there would only be:
master
branchdevelop
branchEverytime a developer has finished its task - even the smaller ones - they open a pull request directly on master.
Now, letās say that everytime something is merged on master
, it goes to production. Scary right? But it solves the developers problems:
- No stress at work
+ You create a bug and fix it in less than 5mns IN PRODUCTION
- Building meaningful things and features that reach the end user
+ Everything you do goes to production: you create value on every merge
- As less complexity as possible (who likes dealing with conflicts?)
+ git checkout, open PR, merge on master, that's it
- Relaxed release day (if release days exist)
+ Which release day?
What the product folks want is a working feature and a way to show that feature in production at a given moment (when itās finished for example).
If we use what the developer folks want, the product folks already have half their needs filled. The thing is we donāt have control on what we show to the user since the code is already in production and is available to the end user. So how can we deal with this issue?
Thereās one technic or practice called Feature flagging which is a way to conditionally show or hide some part of an application. Think of it like a light switch.
Letās say you have a new feature in a React component and you want to show it only when itās ready:
const App = () => {
const flags = useFlags();
return (
<div>
{flags.newFeature ? <NewFeature /> : null}
<SomeOldComponnet />
</div>
);
};
The feature will only be available if the flag is activated.
Now imagine that you could target some specific users, like your product folks for example, so that they have access to the feature before the rest of the world and make verifications directly in production.
Letās see how this solves the product folks problems:
- Features that reach production at a given date (often the fastest right?)
+ They have control with the feature flag on who can see the feature or not when they want
- Features that work
+ They can verify earlier AND they can switch OFF the feature if it completely breaks for some reasons
- Quick bug fixes
+ Fixed by What the developers want
The first thing is to automate the deployment process.
Once the application can be deployed in a consistent way, often, itās time to think of a potential solution for feature flagging. If you need some runtime solutions (something that is real time), you can use existing services or solutions like:
If you donāt really care adding an additional commit to switch a flag on, you can simply rely on environment variables. This is particularly useful for Statically Generated Site (by Gatsbyjs) for example.