About Git Branching Strategies

Just passing by to remind everyone that your Git branching strategy should be as simple as possible for your current situation, and 9 out of 10 cases, you should be using Trunk Based or GitHub Flow.?

Trunk Based:

• Only one branch for everyone;
• Engineers keep their local master branches updated as much as possible;
• Changes in very small batches;
• Commit and push directly to the origin master as much as possible, multiple times a day.

This strategy is of course the most indicated when you have highly extensive automated testing, feature toggles to prevent unwanted features to be deployed, and engineers who are actually interested in the project. If done correctly you will avoid having to deal with “merge hells”. Of course this doesn’t mean that every minor change will be shipped to production, it’s very easy to set up a CI/CD system where a senior can review and choose when to ship to prod.

Github Flow (AKA Feature Branching):

• Engineers create a branch from the origin master;
• They make all the changes so that the feature is functional and make a Pull request to the origin master when it’s ready;
• The rest of the team chimes in, evaluates and discusses the PR;
• PR is merged into the master

This is similar to Trunk Based, but with the addition of the PRs. These feature branches should ideally not last longer than a couple of days, otherwise simply break up the feature into smaller ones and use feature toggles like for the Trunk Based. Likewise, everything on the master branch should be considered deployable(doesn’t mean it will be). Another important notion is that you don’t need to only open up a PR when everything is ready. You can (and should) open a PR so that you code can be reviewed and discussed by your team at any time.

Release Branching:

• Instead of small changes or isolated features, teams will be working on full release cycles. And multiple teams can be working on different release cycles at the same time.?
• Each of these releases would be a different branch, and they can last months.
• Bugfixes/hotfixes would need to be merged into each different release branch and also on the master branch

This strategy is only indicated when there is a real need to support multiple versions concurrently. This adds a fair bit of complexity and overhead. Expect to see merge conflicts, integration issues and long meetings. You will probably need a couple of guys just to orchestrate and organize the branches.

Git Flow:

• Multiple concurrent branches are created. Master (mirror of the production code), Dev (where ongoing changes are merged into), Release Branches(once everything is green, a release branch is created and merged into the master).?
• You also have the feature branches created from the dev branch, and the hotfixes ones that need to be merged into the dev, release and master.?

As you can see, this is overly complex for no good reason. You can forget about any sort of useful CI/CD because nothing continuous here. You need to keep a mental note of every single branch that is being worked in parallel and spend days sorting out merge conflicts. To me this approach comes from an antiquated mentality that still sees the engineers as people incapable of having the minimal social skills to come to an understanding about how to work as a team for a common goal - where everything is compartmentalized and isolated.?

Environment Branching:

All the unnecessary complexity from Git Flow with the added nightmare of having the same confusion duplicated for each environment. Clearly this can only exist in a team that doesn’t understand that we don't deploy code directly to a specific environment, instead the releases are distributed to different environments as needed.