A few years ago, I did a talk called Committed to Good Commits at TechMixer University, CodeStock, and HUNTUG. I said I’d probably never give the talk again. It gets kind of awkward. Not many people show up when there are other talks going on about the new shiny hotness, and those who do show up already agree with everything I say. We just end up nodding our heads and smiling at each other.

For a while, I’ve considered turning the talk into a blog post series. Today is the day!

Like the talk, this series will try to be version control agnostic. While examples will be in Git, the concepts should apply equally well in TFS, SVN, SourceSafe, or what have you.

Much of this will be opinion, but these are practices and principles that have worked for me. That said, we will cover

  1. Commit Messages / Comments
  2. Validation
  3. Work Item Association
  4. Atomic, Frequent Commits
  5. Synchronization / Integration
  6. Team Signals
  7. Branching Strategies

No One Talks About This⌗

Along the same lines, a few weeks ago, a younger coworker noted to me in passing that he never learned anything about source control in any of his computer science classes. - Jeff Atwood

When I first gave this talk at TechMixer U in 2011, a college senior expressed a similar situation. The class had been exposed to CVS, but only the most basic operations. When I was in college, I used “poor man’s version control” by putting the last good version on a floppy disk. Then I got wiser and kept n-number of “last good” versions in zip files with timestamps for names!

We Need To Talk About This⌗

We can do better. While caring about version control and using it properly is ignored in schools and conferences, it is critical!

Source control is the very bedrock of software engineering. Atwood again

But if you don’t have source control, you’re going to stress out trying to get programmers to work together. Spolsky

People Are Starting To Talk About This⌗

The community is starting to ask a lot more about this, and care a lot more about this. I linked to these three questions when I gave the talk, but I’m sure there are plenty more (plenty better?) examples by now.

  1. http://programmers.stackexchange.com/questions/109523/how-do-i-convince-my-fellow-devs-to-want-to-add-comments-to-source-code-commits
  2. http://programmers.stackexchange.com/questions/107884/to-branch-or-not-to-branch
  3. http://programmers.stackexchange.com/questions/98580/whats-the-work-flow-with-2-people-on-a-project

It’s Not Automatic⌗

This stuff does take some discipline. For some people, it’s only after dealing with a painful situation due to poor version control practices that they choose to care. For others, knowing that the pitfalls exist is enough to spark them toward preventative measures, and they care earlier. In either case, it’s important to realize that bad things will happen even to the most careful developers, and that’s ok. It’s how we learn. I’ve certainly been sloppy myself, but try to get better all the time.

I’m going to try not to preach much in this series. We’re going to look at real issues, and some thought processes toward practices that can ease the pain points. It will then be up to each person / team to decide what processes are or are not appropriate for their workflows.