Git Flow and Github Checks with Hotfix

Gitflow

Gitflow is a branching model for Git, specifying branch management approaches. Gitflow is becoming a popular standard for Git branch management, since it’s very well suited to collaboration and scaling development teams.

Hotfix

A Workflow is specified for handling Hotfix changes when the production app needs urgent change. To implement an urgent change, a Hotfix branch is created off the Main branch to test and implement the fix.

Once it’s complete, the Hotfix is merged with the Main branch. Plus, to keep the development branch up to date, the Hotfix is also merged with the Develop branch.

Modern DevOps practices mean that a Continuous Integration Workflow will run, which tests the Hotfix before deployment. A testing Workflow will also run against the Develop branch.

Github Checks

Github provides the Checks API that is used by Bitrise to record the success or failure of testing on a commit. The information is marked against a particular commit.

Pull request triggers

Pull request triggers can be set up in Bitrise to run particular Bitrise Workflows. For the Git Flow Hotfix completion process, where the Hotfix code is merged both into the Main and the Develop branches, pull requests are created for each of the two merges. 

The pull requests will trigger Bitrise Workflow(s) to run to merge the Hotfix into Main and Develop. 

Edge Case

In normal cases, the two Workflows will run and succeed. Github will update the check status for the commit. 

The commit is contained in both pull requests, with one merging to Main and the other one merging to Develop. Both pull requests will then show the check status as success.

However, because the Develop branch continues to evolve with new commits while the hotfix is still being worked on, it’s possible that the merge to the Develop branch will produce errors when the CI Workflow runs. This error status is reported against the check status for the commit. 

The same commit is part of the pull request to Main and the pull request to Develop. The CI Workflow updates the check status in each case. If the Develop pull request Workflow fails, the Main pull request Workflow will also pick up the check status of failure. From the CI Workflow point of view, this is not accurate: the CI Workflow for Main completed successfully, but it is a consequence of the pull request for one commit on two different branches being merged and tested independently, whereas the result is in just one commit’s check status. 

The sequence is also important, because the Github check status records the latest check setting. So, if the failing Develop build completes after the succeeding Main build, then the status of the Main check is reset back to fail, because it is commit specific.

The pre-merge toggle of the Git Clone Step

By default, the Git Clone step will create a temporary pre-merged branch combining the source branch with the target branch, which allows the Bitrise Workflow to run against the result of the pull request being accepted. The aim of the Workflow against a pull request is to check the results of the merging of the pull request. 

Switching off the pre-merge toggle

By switching the toggle to no, the Workflow will treat the pull request as a Push on the Hotfix branch. In this case, the code contained in the Hotfix will not incorporate changes that have been made to Develop after the Hotfix branch was created from the Main branch.  

One solution is switching off the toggle to manage the edge case of Hotfix changes triggering both a success and a fail on the same commit, contained in two pull requests. One that triggers  the CI Workflow for merging into Main, and the other triggering the CI Workflow for merging into  Develop. 

If this event occurs, awareness of the Github Checks edge case for Gitflow and CI Workflows will help you manage it.