Advanced git

Block 2.2: Trunk Based Development

Jan Simson

What is Trunk-Based Development?

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

From https://trunkbaseddevelopment.com/

What is Trunk-Based Development?

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques.

They therefore avoid merge hell, do not break the build, and live happily ever after.

From https://trunkbaseddevelopment.com/

What is Trunk-Based Development?

  • Development happens on a single main branch (trunk)
    • At most short-lived feature branches
  • Developers commit changes directly to the main / master branch
  • Integrates with continuous integration and continuous delivery

Brief Detour: CI / CD 🤖

  • Continuous Integration (CI)
    • Integration of changes from multiple developers into shared repository with automated testing.
  • Continuous Delivery / Deployment (CD)
    • Automated deployment of changes if previous tests pass.

More on these later… ⏲️

How to Get Started with Trunk-Based Development

  • Avoid long-lived branches
    • Use a single trunk instead (doesn’t need to be called so)
  • Use feature-branches
  • Merge / pull / push often and regularly
  • Make sure that any changes you merge can build / run (!)
  • Set up a CI/CD pipeline (⏲️)

Advantages of Trunk-Based Development

  1. Faster Feedback: Immediate integration identifies conflicts early
  2. Reduced Merge Issues: Smaller, more frequent merges minimize conflicts
  3. Promotes Collaboration: Encourages teamwork and shared code ownership
  4. Simplified Deployment: Continuous integration allows for quicker releases

Best Practices: feature-branches

  • Work in separate branches for each new feature
  • Keep them short lived
  • Naming
    • feat-xyz
    • <username>/feat-xyz

Best Practices

  • Feature Toggles: Enable features selectively without affecting the main branch
  • Code Reviews: Ensure high-quality code before merging to trunk
  • Automated Testing: Comprehensive test suites to maintain code stability
  • Monitoring and Rollbacks: Quickly identify issues and revert changes if necessary

Further Reading 📚️

gitflow 🌊

Formerly highly popular workflow, now a bit out of fashion.

  • Development happens in develop branch
  • Only releases e.g. v1.2.1 in main / master
  • Features also in feature-branches
  • Branches are much longer lived
    • Can lead to difficulties with merges
  • Many more active branches in general

Questions?

Speaking of Best Practices: READMEs 📑

  • First touch point for anyone coming to your project
  • Markdown formatted file named README(.md) in root
  • Should (almost) always be present
    • Even if only used by you

Example: https://github.com/pcottle/learnGitBranching

Practical: README 📚️

  1. Add a README to your git-example repository

End of Block 🎉

Any Questions?

[🏡 Back to Overview]

[⏩️ Next Block]