Why Source Control Matters and Hopefully it’s Git

I had an interesting and fun discussion last week with my fellow Headspring employees. I’m a big advocate of using git and I’m also the type of person that likes clean code and clean commits. Combining these two things and my own personal opinions, this means I:

• Don’t commit commented code (actual code commented out, not notes or todos in comments)
• Don’t commit nonsense like whitespace at the end of lines or extra line breaks for no reason. My IDEs and text editors show whitespace! This is actually important when looking for logical changes to a file over time. I don’t want to sift through garbage.
• Commit only working code (can be run/compiled and tests passing).
• There are some version control systems that let you commit/push code without commit messages. That’s just dumb to me. (Yes, I know somebody can just put a single character as a message “to get by”, but it becomes pretty clear who cares versus who doesn’t at that point)

I have strong feelings about this, but I haven’t yet fully figured out why I feel that way about these things. My knee-jerk thought is that I want to be proud of my code base and not ashamed. To me, this is the difference between a house from hoarders and a museum, no to be completely overdramatic. I realize that code that isn’t in production is worthless and crappy code bringing in money is better, but come on, how long does it take to add a message? You can also clean your code in a single key stroke with good add-ons.

In my years of working with teams that use source control, I feel there is a direct correlation between the care that is given to the code base and the quality of the code that is produced. If you don’t have standards (even very loose ones) about what is saved in your VCS, you likely have a crumby codebase and a product of equal quality. If you’re careful about what gets pushed/committed, you likely have a solid product, great team, and well thought out code.

Just sayin…