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

  • Branches can be thought of as “versions”. Each branch that is merged into head / trunk / default / master / main is considered a new version of the source code (and thus a new version of the software is created after the source code is built)
  • If a user pushes their changes to the repo there may be conflicts because another user updated the same file at an earlier point in time
  • When this happens there is a “merge conflict” and it is up to the user to choose what to do (overwrite the other user’s changes, undo their own changes, etc)
  • Resolving merge conflicts is a manual process and an infrequent occurrence that must be resolved before a branch can be merged
  • Google does not use git / GitHub due to their scale but instead uses a custom system
  • WIP = “Work in Progress”, a term for a branch that is under development and is not yet ready to be merged into the head / trunk / default branch
  • Technology is only part of version control. There are development methodologies and human habits and patterns along with that
  • Some examples of the human habits and patterns that are used with DVCS are “commit quickly to make small changes” along with naming conventions, etc
  • When making changes one must consider where the changes will be made...
    • If I need to rename a widget do I rename it in the master / trunk / head branch only?
    • Do I rename it in all committed branches?
    • How do I deal with people who have WIP branches on their laptop so they are not surprised that the widget has been renamed when they commit their changes?
  • Branches that are committed and pushed back to the main repo should be tested extensively before being merged into head / trunk / default
< BACK NEXT >
Tweet


   


   

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