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…

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in Best Practices, Continuous Improvement, git, Project Management, Rant and tagged , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    While I agree with what you are saying, I don’t get how the title of the post is related to the post’s content. A better title would be “Clean commits matter.”

    • @leddt, You’re right, that is better. I’d like to improve my writing. Thanks for the feedback!

    • The unwritten tie to Git is that it, more than any other VCS (to my knowledge), provides features to make clean commits possible and productive.

  • Tudor

    Any current SCM (TFS, SVN) can be easily configured to make comments mandatory and to run some kind of “code quality tool” before each commit automatically.

    Git is nice, but very few developers today are used to it.

  • James Banner

    Mercurial is pretty much similar, I don’t quiet understand the push for “GIT” only? This is not just related to your post, but a movement in general.

    • Git’s branching is much better because it’s so much lighter weight than Hg’s. A lot of the workflow I like and use in git only comes with hg with the use of extensions that need to be downloaded. It’s just easier for me to use git.

      • James Banner

        It will be great if someone does a fresh GIT vs Mercurial comparison with latest versions of both.

  • Steve Friend

    “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! “  Can’t your diff tool ignore them?  If you have a tool to remove them, why not do it automatically when you diff files?

    More important are missing letters “no to be completely overdramatic”, hard for a machine to parse, but easy for a human.

  • Are you inforcing these rules through pre-commit hooks? If not I would recommend it, we can all forget it sometimes. Checking for something like whitespace at the end of lines and unnecessary linebreaks would be really simple.

    I don’t see anything wrong with commit code that isn’t working as long as your on your own branch and you remember to do an interactive rebase where you squash the temporary commits before you merge back to your shared branch. Consider using commits as temporary checkpoints of the state of the code where your always able to revert the code back to be it faulty or not. Maybe you have faulty code and you want to try out one way to solve the problem but later decides that weren’t the best way – now you can reset back to that prior commit and try another path.

    • You’re exactly right on the local commits, the shared commits are what I’m really concerned with. This is why I prefer git to hg, it’s so much easier to have “your own” branches and commits before sharing them with others.