Episode 101: SCM Best Practices
Podcast: Play in new window | Download
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
