Git Strategy Pitfalls

The following diagram shows the GitHub Flow Branch strategy widely used as a basis for software development. The essence of the GitHub Flow Branch strategy is to use the Master Branch as the base for CI/CD practices, which stands for continuous integration, continuous delivery, and continuous deployment.

The developer creates a local branch from the Master branch, for example, to develop the first version of a software product (1) and merges the development result into the Master branch upon its completion (2). From this point on, the CI/CD process begins:

1. A build pipeline that watches for any changes in the Master branch, builds the code located in the Master branch, runs automated tests, and if all tests pass, creates an artifact in a predefined location.

2. The release owner runs the release pipeline to deploy the artifact to the appropriate environment based on the instructions received. The diagram above shows that the same artifact has been deployed to all four environments. Deployments typically occur when management decides to do so and in a logical sequence, such as development, QA, user acceptance testing (UAT), and production.

Despite its simplicity and popularity, the GitHub Flow Branch strategy has its main drawback, which lies in the very nature of the strategy – using a single Master branch.

Let's look at the Master branch timeline to see how its simplicity quickly turns into complexity when non-trivial situations arise.

The following diagram shows a situation where three different versions of a software product are deployed: version 1 in production, version 2 in UAT, and version 3 in QA and Dev environments, development of version 4 is started, and a problem is discovered in production:

It is not possible to create a local branch from the master branch to fix issue (8) because the master branch already contains code that is two versions ahead of version 1 where the fix is needed.

The only way is to find the code check-in that corresponds to the first product version in the check-in history, create a Hot Fix branch from it (8), redirect the build pipeline to it, create a developer's local branch from the Hot Fix branch, perform the fix there (9), and merge the code into the Hot Fix branch:

And this is just the beginning of the challenges, as we need to extend our fix to UAT, QA and Development environments as well.

To deploy our fix to the UAT environment, the following steps need to be taken according to the following diagram:

find the code check-in that corresponds to the second product version in the check-in history, create a Hot Fix branch from it (10), redirect the build pipeline to it, and merge fixed code into the Hot Fix branch (11):

To deploy our fix to both QA and Dev environments (we are lucky that both environments have the same product version), the build pipeline needs to be redirected back to the Master branch, and the fixed code needs to be merged into the Master branch (12):

As you can see, the GitHub Flow Branch strategy is not suitable for fixing bugs when it needs to be done in parallel with ongoing development.

Last but not least, continuous deployment is not good enough from a psychological point of view. Frequent updates irritate users and give them the impression that the software product is unstable and poorly designed if it needs to be updated so often.

Table of Content Software Development Pitfalls Previous: Business Logic Development Pitfalls Next: Demystifying Unit Testing in Business Domains