Why?

• Organize Developmental workflow.

• Facillitate better collaboration in teams.

• Manages Code Integration

• Reduces risk of introducing bugs.

What? - Long Living Feature Branches (Git-flow)

• Goal - Simplify release management and isolating feature development.

• Feature based development (Git-Flow workflow)

• Developers create separate, long lived branches for individual features.

• Depending on complexity, feature branches can be active for days, weeks or months.

• Once the feature is complete and thoroughly tested, it can be merged back into the main branch.

Gitflow Diagram

Benefits of Git-flow

• Isolation of work:

  • Features are developed independently, reducing the risk of conflicts.

• Controlled Integration:

  • Code is reviewed and tested before merging.

• Supports Complex Projects:

  • Easier to manage large, multi-feature projects.

• Flexibility:

  • Different branching strategies can be adapted to team needs.

Disadvantages of Git-flow

• Complexity

  • Managing multiple branches can become complicated.

• Long Living Branches

  • Feature branches can diverge significantly, leading to merge conflicts.

• More Overhead.

  • Time consuming to review PR's and testing.

What is Trunk Based Development?

• Goal - perform small incremental updates to minimize merge conflicts, and streamline the dev pipeline.

• Developers collaborate frequently on a single shared branch: "trunk" or "main".

• Frequent commits to the trunk, often multiple times a day.

• Short-lived branches are allowed, but are merged back to the main branch quickly.

Trunk Based Development Diagram

Benefits of Trunk Based Development

• Continuous Integration (CI)

  • Easier to integrate changes continuously.
  • Promotes frequent and smaller releases.

• Reduced merge conflicts

  • Less branching means fewer conflicts to resolve and less code to review.

• Faster feedback loops.

  • Immediate feedback on changes.

Disadvantages of Trunk Based Development

• Requires Discipline

  • Developers must commit to working code frequently.

• Risk of Breaking Changes

  • Changes committed to the trunk can affect all devs.

• Not ideal for Large Teams

  • Scaling can be challenging in large and distributed teams.

CASE Study

Background

In Autumn of 2023, we decided to undertake a major refactor of Splink. This refactor was a necessary step to help us improve the performance and maintainability of the library.

However, for the first few months of this process, we had ongoing development in both versions 3 and 4. This was due to:

• Team members were actively developing data linking pipeline features, all required in version 3.
• There were ongoing features in version 3 that needed finalization.

The problem

Initially, we were infrequently merging changes from the main branch into our development branch. This led to regular divergences between the two versions and we were constantly resolving relatively large merge conflicts.

This raised a question around version synchronization:

• What's the best strategy for keeping the new version updated with changes from the main branch?

A solution?

• GitHub Action creating merge branch on push to main
  • Automatically create a new merge branch (main -> splink_4_dev) on push to the main branch
  • If no merge conflicts are detected, we could then create and merge the PR
  • If conflicts were present, we then had earlier sight of them

This ensured splink_4_dev was consistently updated with changed from the main branch, with regular merge PRs replacing ad-hoc updates.

Findings from experiment - Pros

Pros

• Reduced manual intervention: Eliminated the need for reminders or scheduling, ensuring continuous integration without extra effort.
• Reduced size of conflicts: Reduced the potential for large merge conflicts. Particularly troublesome to resolve as multiple developers were working on the same codebase.

Findings from experiment - Cons

Cons

• Didn't solve all of our problems: While it helped with synchronization, it didn't fundamentally fix our issues with a diverging codebase and stale code.
  • Required the structure of each branch remain consistent, which was only feasible in early development.
• Overkill for our needs: A simpler notification system might have been more appropriate and less faff to set up.

Case Study Summary

Overall, this solution worked acceptably. The main benefit was in allowing us to quickly review if/where merge conflicts were occurring. We could then identify and resolve issues early on.

However, it didn't fundamentally resolve a lot of the issues we were encountering with the branches steadily diverging. Later in development we decided to stop actively working on version 3, and focus on version 4.

create-a-pipeline - Linting Case Study

• PR - #350

• Refactor all of our linting tools.

• Everyone was on different components, and it was a major change on how we approached linting in the codebase.

• Used long living branches to manage each componential change.

Linting

Best Practices

• TBD

  • Commit often with small incremental changes
  • Use feature toggles to manage incomplete features

• Feature-Based

  • Keep branches short-lived to minimize divergence.
  • Ensure thorough code reviews and testing before merging.
  • Regularly rebase feature branches on the main branch to reduce conflicts.

Other Best Practices

• Pair experienced developers with those new to a codebase.
• Communication, Communication, Communication

Discussion Questions:

• What have people done before which has been successful?

• What should be considered a long living branch? (a few days, weeks? etc.)
  How long is too long? (Month? Year?)

• Other strategies for managing long living branches.

References

• Git Branching Strategies vs Trunk Based Development - Launch Darkly BLOG

• Git Branching Strategies - Medium

• Git Workflow - Atlassian

• Trunk-Based Development - Atlassian