Git Workflow Environments (Pronghorn)

3.2 Git Workflow Environments

Working with Git should be done in an organised and responsible way, as Linus Torvalds originally intended. The idea under a continuous development, integration and deployment (CI/CD) pipeline is that, depending on the actions performed on specific branches of the code repository, different actions will be executed according to the time and state of the product.

The two workflows that will be discussed in this paper are: Gitflow, created and published by Vincent Driessen back in 2010⁽⁴⁾, and Trunk Based Development (TBD), first created by Paul Hammant in 2017⁽⁷⁾, and later extended with the help of multiple collaborators around the world.

With Gitflow, we have different types or classes of branches, each of them having a very specific role and interaction policy with the rest. Instead of using a single core/trunk branch, like the original Git design, it uses two main branches, ‘master’ (production) and ‘develop’ (development), each of which defines and describes a different environment. All new features and changes to the source code are implemented in ‘feature-*’ branches, which are forked from and merged to the ‘develop’ branch. When a set of new features is ready for release, a ‘release-*’ branch is forked from the ‘develop’ branch, it only can implement small bug fixes and documentation additions and changes, and is merged to both ‘master’ (as a new production version) and ‘develop’ (as a synchronization method between the development and the production versions) branches. Last but not least, we have the ‘hotfix-*’ branches, which are intended to quickly fix issues in production releases, and are forked from ‘master’ and merged to both ‘master’ and ‘develop’ branches; they can be considered naturally analogous branches to the ‘release-*’ ones, having as counterpoints their existance rationale (user bugs vs. developer bugs) and their fork point (‘master’ vs. ‘develop’).

Figure 3.1: Gitflow diagram; see 4

Unlike Gitflow, Trunk Based Development (TBD) promotes a simpler and more streamlined development process by encouraging developers to work directly on a shared ‘trunk’ or ‘master’ branch. In TBD, feature branches may exist, but they should be short-lived, so do not always wait until the feature is completely finished and tested to merge it to master. Therefore, this workflow was designed with Continuous Integration (CI) in mind, to be able to maintain code quality and ensure that changes are seamlessly integrated into the ‘trunk’. However, TBD may not be suitable for all projects or teams. It requires robust automation and test coverage to ensure the stability of the trunk branch. Additionally, it relies on feature flags, which can introduce complexity and require careful management to avoid feature creep or technical debt.

Figure 3.2: TBD diagram

This workflow can be easily and efficiently integrated with the Ship/Show/Ask philosophy and branching strategy⁽¹³⁾, which considers three different options when wanting to merge to ‘master’ a specific feature:

‘Ship’: This option involves committing directly to ‘master’. This is aimed to small and minor adjustments, bug fixes, and documentation additions and changes.
‘Show’: This option involves creating a Pull Request (PR) to merge the changes, wait for the CI checks to pass, and, only then, merge it right away to ‘master’. Your team will receive a notification about your PR, allowing them to review your work, offer you feedback, and ask you questions about the code committed.
‘Ask’: This is the traditional option, where we wait for approval before merging the changes to ‘master’. The approval is never a requirement for a PR to be merged, instead we use it to ask for different opinions on a specific approach, or maybe because we do not know how to further optimize a certain piece of code.

Table 3.1: Ship/Show/Ask strategy