What is trunk-based development? | Git branching strategies (2023)

This post was written by a guest author.

When there are many software developers working on the same project, it is crucial to keep track of individual changes and previous versions, especially as this helps to avoid conflicts that slow down the development and deployment process. For the majoritydevelopment teamsAround the world, Git is the preferred system for organizing files and software versions.

From the beginning of a project, your team should select a development strategy and ensure that all team members apply it consistently throughout the entire workflow. Choosing the right strategy depends on a few things, including the size of your team, the complexity of the software you're developing, and other tools you're already using. You should also consider how your team prefers to work together and the knowledge and experience of each team member.

This article will highlight trunk-based development, including benefits and best practices, as well as someGit branching strategies:the workflow, GitHub stream, and GitLab stream.

• What is trunk-based development?
• Benefits of trunk-based development
• The cons of trunk-based development
• Trunk-based development best practices
• Popular Git branching strategies
• Development based on Gitflow x Trunk

What is trunk-based development?

Trunk-based development is clearly different in approach from more popular Git branching strategies. Rather than relying on feature branches, trunk-based development has each developer work locally and independently on their project and then merge their changes back into the main branch (the trunk) at least once a day. Merges must occur regardless of whether feature changes or additions complete or not.

Patrick Lee Scott describes how to approachTrunk based development with GitIn an article for HackerNoon:

“…We're going to have to approach things a little differently than you're probably used to. We still want to tie some actions to commits, but not so many different concepts: we just want to do things related to the code base we're working on. Instead, we can limit that action to releasing a new versioned artifact from the project we're working on."

Emanother article, Ben Morris explains:

“Trunk-based development is more than just a branching strategy. It is a set of techniques that can help enable more efficient development.

use of equipmentderivationbyabstractionto separate work into large-scale features. Abstraction layers isolate the work in progress and allow multiple implementations of functionality to exist in the same code base. A system can be safely trunked despite having many incomplete functions.”

Benefits of trunk-based development

Trunk-based build strategies are less complex than traditional Git branching strategies, as they generally involve fewer branches and less risk of failure.Git merge conflicts. Trunk-based development is also uniquely suited for use in CI/CD methodologies because the trunk is constantly deployed.

Regular updates provide greater visibility into the status of project changes for the entire team. As a result, teams can more quickly identify and resolve potential merge issues. Compared to Gitflow, where long periods can elapse between merges, increasing the chances of conflicts, trunk-based development limits the risk of conflicts. With trunk-based development, a fall into fusion hell is much less likely.

Collaboration takes place on the trunk rather than on individual feature branches in trunk-based development. However, team members must constantly collaborate to prevent issues from infecting the trunk. In general, collaboration levels should be high and all team members should constantly strive to reach the next goal.

Cliente GitKrakenIt was designed with team collaboration in mind, offering less context switching, better communications, and seamless processes for whatever workflow you prefer.

Due to its agile nature,Trunk based developmentIt can also be very useful in today's microservices and container development environments.

The cons of trunk-based development

Of course, trunk-based development has its problems. Fundamentally, trunk-based development is more complicated than more traditional Git branching strategies, and therefore requires more advanced development skills.

As Ben Morris explains in his article,Why trunk-based development isn't for everyone:

Although trunk-based development can reduce merge conflicts, it does not necessarily reducecomplexityto manage concurrent feature development. In a way, you're just redistributing some of that complexity to other processes like code design and application configuration."

Younger developers are likely to be less confident using trunk-based development, as changes go directly to trunk rather than intermediate stages like other Git-based strategies. And there are good reasons for this concern. Problems injected into the trunk by inexperienced developers can cause major deployment issues. Therefore, trunk-based development strategies are best when you have smaller teams of experienced developers.

Trunk-based development is also less able to track individual changes. Whilethe workflowis highly organized, uses individual branches for each feature, trunk-based strategies push all changes to the main branch, regardless of its state. It can be easier to lose track of individual parts.

You can enhance your team's Git experience withCliente GitKraken, a tool that allows junior and expert developers to increase their productivity, includinglearn gitResources will help beginners to increase their knowledge quickly.

Trunk-based development best practices

As mentioned above, a smaller team with advanced development skills will be more likely to succeed with trunk-based development strategies.

You should also make sure that you have a codebase that supports function abstractions and that you are prepared with a solution for function flags.

Finally, invest in an ongoing build and test infrastructure and streamlined processes for reviews and releases that can accommodate a high commit rate.

Popular Git branching strategies

Compared to trunk-based development, the following Git branching strategies are workflows that make it simpler and less error-prone to have multiple parallel development paths for an application. Simpler forking strategies in Git can help inform individual developers how to integrate their changes into the main production version of the code.

Well-chosen Git branching strategies offer development teams many potential benefits, including:

• Rationalization of parallel development
• Promote efficient team collaboration
• Provide clear development workflows to integrate changes into production code
• Minimize Git merge conflicts
• Limit the introduction of errors in production code
• Provide an optimized roadmap for new releases

The most popularramo gitStrategies include: Gitflow, GitHub flow, and GitLab flow.

the workflow

Historically, Gitflow has been one of the most popular fork strategies forteams using git. The strategy uses five different types of branches in total: two main branches: thedirectoryto developbranches, along with three special purpose branches such asfeature,release, yourevision. The main branch of Gitflow uses tags to identify specific production versions (0.1, 0.2, 1.0 as shown in the diagram below). Development branches are cloned from a tagged major branch version.

With Gitflow, many developers can work in parallel, collaborating on feature branches before new candidates are released. And because Gitflow uses a separate sandboxed staging area for releases, it can help development teams ensure that only verified functionality makes it to production. Separate release branches also allow teams to easily integratesecurity by design principlesin the development process.

Special purpose branches are created from the development branch, and multiple special purpose branches can exist concurrently. While master and development branches are perpetual, feature branches typically only exist for as long as it takes to complete a specific task, which can take days, weeks, or even months.

Teams work directly together on feature branches. As they finish developing a feature, they merge it back into the development branch. There is no set timeline for merging new features: merges happen on an as-needed basis.

In addition to feature branches, developers can work with hotfix branches to quickly resolve issues in production code. Unlike feature branches, hotfix branches extend from the main branch. However, developers must remember to merge completed patches into the main and development branches.

Development teams can clone a release branch from the development branch. The release branch serves as a testing and QA sandbox for new release candidates. As with hotfix branches, mods completed on the release branch must be merged into the main and development branches.

Vincent Dreissen, the creator of Gitflow, has created a usefuloverview graphic summaryof the various branches of Gitflow and how they relate:

Development based on Gitflow x Trunk

With its highly organized, well-defined, and well-segregated structure, Gitflow makes it easy to know what's going on in a project at any given time. However, adding multiple branches increases the risk of merger conflicts. And the larger the team, the greater the risk of introducing issues into the core codebase.

Since Gitflow's strategy requires a developer to perform many different commits before code is released, project history can become difficult to analyze. Tracking bugs through the complex network of branches and commits can be time consuming and frustrating. In fact, while Gitflow aims to accelerate development, if individual developers don't understand how to properly implement the strategy in their workflow, they are unlikely to be successful.

If your team needs more visibility into their project history, a robust and easy to useGit graphical user interfacehow the GitKraken Client can make a world of difference for developers of all skill levels. SettingGitflow not GitKraken clientit is extremely easy and intuitive, requiring only 3 steps.

The complex nature of Gitflow and the lack of defined times for commits on the master branch also make it unsuitable when teams want to deploy.continuous integration/continuous delivery workflows (CI/CD). By its very nature, continuous integration relies on regularly and periodically merging code changes into the main branch. On the other hand, if your project allows for longer periods between deployments, Gitflow can be a great option.

Likewise, continuous delivery requires the ability to go into production immediately. On Gitflow, however, developers must create a release branch, merge it into the main and development branches, and tag the new production version into the main branch before the changes go into production. In fact, Gitflow encourages a batch delivery process more than a continuous one.

GitHub Flow

GitHub Flow is a simplified version of Gitflow that removes the development and release branches. Instead, feature branches come directly from the parent branch.

With this strategy, developers push changes to the feature branch and test them there as well. Only after making a decision do developers merge the feature branch into the main branch.

WhyGitHubflow lacks Gitflow's intermediate branches, the story is easier to follow. And unlike Gitflow, GitHub Flow easily integrates with CI/CD pipelines.

One disadvantage of the GitHub flow is that not properly testing feature changes before merging them into the main branch can lead to buggy and unstable production builds.

Because it's lightweight and faster than other Git forking strategies, the GitHub flow works well for small teams that apply agile development principles. However, as teams grow, the GitHub stream loses its beneficial qualities.

Stream from GitLab

Another simplified version of Gitflow,GitLabGenericNameflow uses a pre-production branch to test changes before merging them back to the main branch and moving to production. GitLab's flow focuses on tracking issues, creating useful stories as new features are merged into the main branch. And just like the GitHub flow, the GitLab flow is more viable when working with CI/CD.

Is trunk-based development right for you?

Trunk-based development and other branching strategies have areas where they excel and where they lag. Fortunately, if your needs or circumstances change during a project, it's possible to switch from one strategy to another.

Tracking changes and versions throughout the software development lifecycle is a crucial but far from simple task. Ultimately, trunk-based development and Git's popular forking strategies should provide developers with the tools they need to ensure robust and stable production releases, while allowing them to roll out changes as often as they wish. .

As with most tools, there is no "one size fits all" solution. Consider the makeup of your development team and the needs of each specific project to decide which path is right for you. And if you don't succeed at first, switch to another approach. It really is as simple as that.