Software Engineering at Google Chapter #16 - Version Control and Branch Management (3 of 3)

  • A frequently used pattern is the “feature branch” or “dev branch” pattern. Each new branch maps to a new feature of the software, a JIRA ticket, a bug report, or similar
  • The disadvantages of feature or dev branch pattern are twofold:
  • It leads to large commits (changes). The larger the commit the harder it is to understand what changed. Smaller commits take less mental overhead.
  • It takes more effort to keep things in sync both from a human and technical perspective. If it takes a long time to finish the branch then when it comes time to merge into default / trunk / head there may be many merge conflicts because the trunk branch has changed so much since the user started on their feature / dev branch
  • Trunk-based development is when all commits are merged directly into the main / head / default / master branch. In other words users do not create their own branches.
  • In trunk-based development there is a true single source of truth (the main branch). When using a feature or development based method there are multiple sources of truth (trunk and the WIP branches on each developer’s laptop)
  • Trunk based development requires little or no coordination because many small commits are made to the main branch
  • Instead of a dev / feature branch pattern Google recommends trunk-based development with heavy Continuous Integration and pre-build testing
  • Overall Google sees non-trunk development as a crutch for lack of testing. More testing brings more confidence
  • A release branch is all of the exact code that was pushed to production
  • At Google “every build job needs to be rebuilt and redeployed every 6 months”. This ensures each build is working correctly and if not it can be fixed quickly so errors don’t build up over the years
  • One-Version Rule : Don’t give devs a choice about which library to add or where to commit or when to fork. Have a workflow and stick to it for consistency.
  • Google uses a “monorepo” - a single repository for all of the company’s code. Very few companies use this pattern
  • It is hard to do compliance & secrecy if you use a mono-repo because different parts of the repo have different requirements libraries or operating system
< BACK NEXT >
Tweet


   


   

Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.