The models for collaboration with Git

The content here is under the Attribution 4.0 International (CC BY 4.0) license

I have written about Git before, but I have never written about the models for collaboration with Git. In this post, I will explore the different models that can be used to collaborate with Git (Shakikhanli & Bilicki, 2024). The goal is to explore the different models and how they can be used to collaborate with teams in software development(Fowler, 2020).

Git is often refered being the same as GitHub or GitLab, but it is not. Git is a version control system that can be used to track changes in files and collaborate with others. GitHub and GitLab are platforms that provide a web interface for Git, but they are not the same as Git. Git is a distributed version control system, which means that every user has a complete copy of the repository on their local machine. This allows users to work offline and commit changes without needing to be connected to a central server.

 ---
 title: Git Collaboration Models Timeline
 ---

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#c2f0f7', 'edgeLabelBackground':'#ffffff'}}}%%
timeline
  title Collaboration Models in Git Timeline

  section Early Days (1990s)
    event Trunk-Based Development (1995) as "Trunk-Based Development Emerges"
    note "Early days of Git collaboration"

  section Mainstream Adoption (2000s-2010s)
    event GitFlow (2011) as "GitFlow Emerges"
    event GitHub Flow (2013) as "GitHub Flow Gains Popularity"
    event GitLab Flow (2014) as "GitLab Flow Becomes Popular"

  section Peak Popularity (2015-2020)
    event Scratch-and-Patch (2016) as "Scratch-and-Patch Emerges"
    event Pull Request Workflow (2018) as "Pull Request Workflow Gains Popularity"
    note "Collaboration models reach peak popularity"

  section Future Developments (2020+)
    event Centralized Workflow (2022) as "Centralized Workflow Emerges"
    note "New collaboration models continue to emerge and evolve"

However, given their poplarity and the fact that they are often used in conjunction with Git, they are often used as a reference point for the models of collaboration with Git. In this post, I will explore the different models of collaboration with Git, including the centralized model, the distributed model, and the hybrid model.

Gitflow

Gitflow is a branching model for Git that was introduced by Vincent Driessen in 2010. It is a popular model for collaboration with Git, and it is used by many teams to manage their development process. The Gitflow model is based on the idea of having a main branch (usually called master or main) and several supporting branches for features, releases, and hotfixes.

The main branch is used for production-ready code, while the supporting branches are used for development and testing. The Gitflow model is designed to be flexible and allow teams to work on multiple features and releases at the same time. The Gitflow model consists of the following branches:

• Main branch: This is the main branch of the repository, and it is used for production-ready code. It is usually called master or main.
• Develop branch: This is the main development branch, and it is used for ongoing development. It is usually called develop.
• Feature branches: These branches are used for developing new features. They are created from the develop branch and merged back into it when the feature is complete.
• Release branches: These branches are used for preparing a new release. They are created from the develop branch and merged back into both the main and develop branches when the release is complete.
• Hotfix branches: These branches are used for fixing bugs in the production code. They are created from the main branch and merged back into both the main and develop branches when the fix is complete.

Gitflow in practice

The Gitflow model is implemented using a set of commands that are used to create and manage the different branches. The following commands are used to implement the Gitflow model:

Tools for gitflow

• git flow init: This command initializes the Gitflow model in the repository. It creates the main and develop branches and sets up the supporting branches.

Trunk-Based Development

In the other end of the spetrum, we have Trunk-Based Development (TBD). This is a model that encourages developers to work on a single branch, usually called trunk, main, or master. The idea is to keep the codebase as simple as possible and avoid the complexity of managing multiple branches. This model is often used in continuous integration and continuous deployment (CI/CD) environments, where the goal is to have a stable codebase that can be deployed to production at any time.

Trunk-Based Development in practice

In my experience, Trunk-Based Development is a great way to keep the codebase simple and avoid the complexity of managing multiple branches. It allows developers to work on features and fixes without having to worry about long-lived branches that can become stale or diverge from the main codebase. However, it requires a high level of discipline and communication among team members to ensure that the codebase remains stable and that changes are properly tested before being merged into the main branch. Let me try to explain the points that I have seen that leads to this conclusion:

1. TBD required a high level of discipline and communication among team members to ensure that the codebase remains stable, it means using additional practices in addition to writing code, such as:
   • Writing tests before writing code (TDD)
   • Using feature flags to control the visibility of new features in production

Miss conceptions

The first one is that no branches are created. Branches are still created, but they are short-lived and merged back into the main branch as soon as possible. This allows developers to work on features and fixes without having to worry about long-lived branches that can become stale or diverge from the main codebase.

GitHub Flow

GitHub Flow is a simplified version of Gitflow that was introduced by GitHub in 2013. It is a popular model for collaboration with Git, and it is used by many teams to manage their development process. The GitHub Flow model is based on the idea of having a main branch (usually called master or main) and several supporting branches for features and hotfixes.The main branch is used for production-ready code, while the supporting branches are used for development and testing. The GitHub Flow model is designed to be flexible and allow teams to work on multiple features and hotfixes at the same time.

References

1. Shakikhanli, U., & Bilicki, V. (2024). Analyzing Branching Strategies for Project Productivity: Identifying the Preferred Approach. J. Electrical Systems, 20(9s), 1110–1116.
2. Fowler, M. (2020). Patterns for Managing Source Code Branches. https://martinfowler.com/articles/branching-patterns.html