Source Management

Tags:

  2 minute read  

Use Trunk Based Development

  • All branches originate from the trunk
  • All branches merge into the trunk
  • Branches, if used, are very short-lived
    • The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change.
  • The trunk can always be built and deployed without breaking production.
    • When needed, use techniques such as Branch by Abstraction or feature flags to ensure backward compatibility.
  • The change includes all appropriate automated tests to validate that the change is deliverable.

Branching vs. Forking

Use the right pattern for the right reason. Branches are the primary flow for CI and are critical for allowing the team to have visibility to work in progress that the team is responsible for completing. Forks are how proposed, unplanned changes are made from outside the team to ensure quality control and to reduce confusion from unexpected branches.

  • Use forks for:
    • Contribution from a contributor outside the team to ensure proper quality controls are followed and to prevent cluttering up the team’s repository with external contributions that may be abandoned.
  • Use branches for:
    • All internal work to keep that work visible to the team.

Tips

  • Story Slicing helps break development work into more easily consumable, testable chunks.
  • You don’t have to wait for a story/feature to be complete as long as you have tested that won’t break production.
  • Pull requests should be small and should be prioritized over starting any new development.

Common Issues

Trunk-based development and continuous integration often take workflow adjustments on the team. The main reasons teams struggle with CI are:

References

FAQ

Last modified December 15, 2023: Reorganize (7579932)