Source Control Management: A Guide to Git, Trunk-based Development, and Gitflow Strategies

Source control management is the practice of tracking and managing changes to code. It ensures efficient collaboration within teams or across teams, as well as versioning and managing the needs of the team using different management options such as Git, Tfvc, Svn, depending on their requirements for managing source code. Git, which has become increasingly popular in recent years, especially in open-source software development, plays a significant role and is widely preferred. When selecting a tool for source code management, we can consider the team’s experience, ease of use, and project requirements. In this blog post, we will focus on Git, an open-source tool with a distributed architecture. However, choosing the right source code management tool is just as important as software development principles because it plays a crucial role in how the team develops the software and the software’s lifecycle from the initial development stage to the customer delivery stage. Generally, there are two different principles associated with Git: Trunk-based development and Gitflow.

Trunk-based Development

In the trunk-based workflow, which is used as a principle for source control management, developers collaborate on a single long-lived branch (main), and the main branch should always be deployable. This principle focuses on continuously committing small changes to the trunk and aiming for quick integration and deployment of code to environments. The key feature of trunk-based development is enabling fast development and delivering completed work to the customer in the shortest possible time. Different strategies can be applied based on the team’s size, frequency of deployments, or the team’s level of experience.

For smaller Teams:

In this strategy, which enables fast development for small teams, developers work by making small commits to the trunk (main). When committing to the trunk, it is essential to ensure the health of the code being merged by performing pre-hook validations.

git checkout main

git commit 

git push origin main

When the release is ready, a release branch is created from the trunk. After creating the release branch, no new features should be added to it, and bug fixes should be committed to the trunk instead.

git checkout main

git checkout -b release/1.0.0

For scaled Teams:

In this strategy that enables fast development for large teams, short-lived feature branches are created, and they are sent to the trunk through pull requests (PRs).

git checkout main

git checkout -b feature/abc

git push origin feature/abc

Developers create the feature branch from the trunk, and once their work is completed, they push it to the remote repository and open a pull request (PR).

git checkout main

git merge feature/abc

In a project involving large teams, it is crucial to protect the stability of the trunk through PR code reviews. This practice helps identify potential errors in advance and ensures that the trunk remains stable.

When all the necessary tasks for a release are completed in the trunk, a release branch is created by branching off from the trunk. After creating the release branch, bug fixes should be completed in the trunk, not in the release branch.

git checkout main

git checkout -b release/1.0.0

Trunk-based development is quite similar to the GitHub flow structure. The main difference lies in which branch deployments are made from. In the GitHub flow structure, deployments are always made from the main branch. In trunk-based development, however, deployments are made from release branches. So, is it really important from which branch deployments are made? And in which areas does it help us?

The answer to this question may vary depending on the needs of the teams. However, if a team has a high deployment frequency, such as deploying more than once or twice a day, planning and coordinating these releases can require communication, potentially extending the time required for immediate deployments.

Gitflow

Gitflow is one of the popular git branching strategies preferred by organizations. It enables effective code development for large teams and offers several advantages when developing an established product with a regular release cycle. One of its most significant advantages is enabling parallel development. With its branch structure, completed work is isolated from new development, ensuring that planned tasks are not disrupted. Developers move their development using feature branches over two primary branches, unlike trunk-based development. These primary branches are the “develop” and “release” branches.

In trunk-based development, when developers work on a feature, they branch it of the main branch. However, in Gitflow, the base for feature development is always taken from the develop branch.

If you choose Gitflow as your branching model workflow, the first step would be to create a develop branch from the main branch and synchronize these two branches.

git branch develop

git push -u origin develop

Now, the develop branch is available for software teams to use, and when developers are working on a feature, they need to create a dedicated feature branch for that particular task. It is important to note that each feature should have its own separate branch.

git checkout develop

git checkout -b feature/abc

After developers complete their work in the feature branches, they push their changes to the central repository, and then the completed work is merged into the develop branch. It is important to merge the completed work into long-lived branches like develop through pull requests (PRs). This is because the develop branch is a shared base branch for everyone in the software team and should be as bug-free as possible.

Once all the necessary features for a release are merged into the develop branch, a release branch is created. When creating the release branch, the develop branch is used as the base. This approach allows for parallel release planning while the planned work for the release continues. After the release branch is created, no new features should be added to it. Only bug fixes observed during UAT (User Acceptance Testing) before deployment in the planned release should be merged into the release branch.

git checkout develop

git checkout -b release/1.0.0

When the release is ready for deployment, it is merged into the main branch and tagged with the release number. Additionally, after merging the release branch into the main branch, it should also be merged into the develop branch. This is done to ensure that bug fixes applied to the release branch do not impact newly opened features in development.

git checkout main
git merge release/1.0.0


git checkout develop
git merge release/1.0.0

In the Gitflow branching strategy, hotfix branches are used to resolve production issues. A hotfix branch is similar to release and feature branches but, unlike other branches, it is directly based on the main branch. Hotfix branches have their own unique workflow because they need to be addressed as quickly as possible to fix critical issues without disrupting other planned work.

To start a hotfix, developers create a branch directly from the main branch. After completing the necessary work, the hotfix branch is merged back into both the develop and main branches. This ensures that the fixes are applied to both the ongoing development work and the stable main branch.

git checkout main
git checkout -b hotfix/xyz

Exactly, merging the hotfix branch into the develop branch is necessary to prevent future planned work from being affected by any bugs or issues addressed in the hotfix. It ensures that the ongoing development work in the develop branch remains free from the hotfix-related problems and maintains the stability and integrity of the codebase.

git checkout main
git merge hotfix/xyz

git checkout develop
git merge hotfix/xyz

In summary, popular branching strategies such as Gitflow or trunk-based provide a foundation for software teams to work effectively. The choice of strategy is based on factors such as the team’s experience level, the number of developers in the team, and the need for rapid development. The selected strategy guides the team’s workflow. However, teams may change their working strategy based on future needs and determine the most suitable approach for themselves.