The Purpose of Version Control

I think it's rare to see a project not automatically added to Github shortly after, if not before, inception.  It's just a checkbox of writing code.  Previously it was something to think about.  Github (and Bitbucket, Gitlab, etc) make it supremely easy to get started that you don't even need to touch the command-line to get started.

While this makes it supremely accessible, a lot of nuances get lost.  Here are my opinions as a former web developer at Mozilla and the original "owner" of the Github Enterprise repositories at Pinterest on source control fundamentals.

Source control:

• Keeps a team's code in sync with a predictable process.  300+ engineers may work off the same code base, but they will all reach eventual consistency.
• Be able to work on multiple different tasks at once.  A software engineer may have a feature to build out, but that can be put on hold to handle an urgent bug.  This is supremely easy with version control.
• To be able to go back in time.  Sometimes code behaves a certain way.  We might identify how it does this, but by looking at the history of a specific file or even line of code can explain the why.  

We can leverage much more benefits out of git and any version control if we stick to a few principles:

• The history should be legible.  I should be able to read each commit and have some clue as to what is happening.
• The history should be clean.  Missteps in feature branches, merge commits and other things don't need to exist in the finalized history.
• Each commit should be deployable.  Half-baked code doesn't need to be in your finalized history.
• Each commit should have any relevant tests and documentation bundled together.  If documentation or tests need to be modified to make sense of new code, it should all happen together.
• Don't comment out large blocks of code.  Just delete it.
  

Shoot me an email at git@davedash.33mail.com and let me know if I missed some major points.  Let me know about your git troubles.