Dec 28 2010

Episode 101: SCM Best Practices


A look at source control management best practices

News/Follow-Ups – 01:59

Geek Tools – 04:35

Webapps – 07:43

  • Link Peelr – Find out where those shortened URLs go to
  • Moniitor – Site stats in one place

SCM Best Practices – 13:58

  • #1 rule, use it.
  • Commit Small, Commit Often
    • It’s better to have a broken build in your working repository than a working build on your broken hard drive.
    • You shall religiously backup your source code control database on a regular basis and store a copy in an off-site location
      • Use a service like Dropbox or Github/Bitbucket
  • Don’t break the code. Each commit should keep the code in working condition.
    • Continuous integration?
  • Try to include the intention in the commit message instead of only the “what”. The Why, like code comments
    • If you have nothing to say about what you are committing, you have nothing to commit.
  • Don’t comment out code. Remove them instead.
  • Reference ticket numbers/bug ids in commit messages, tie them together if you can
  • Branch, Branch, Branch
    • Make use of the branch for experimental or potentially code breaking changes.
  • Merge, Merge, Merge
  • Pull often
  • You shall not go home for the day with files uncommitted, nor shall you depart for the weekend or for a vacation, with files uncommitted.
  • Don’t add generated files to the repository
    • Files generated at build time shouldn’t be checked into the repository because this is redundant information and might cause conflicts (Agiletask sphinx documentation)
  • Keep production parameters such as URLs, user names, passwords, etc. outside of version control.  You should have mechanisms to load in configuration files with these values.
  • Don’t commit code you don’t understand
  • Bring everyone up to speed that is using SCM.  It will benefit everyone
  • SCM doesn’t have to be just for code
    • Distributed vs. centralized
    • Server configs
    • Documentation