How to enforce good/better source code control practices?

Question

I suspect that I'm focusing on the wrong problem so I will first describe what I think the problem is before presenting the possibly suboptimal solution I envision.

Current Situation:
Currently my co-workers commit their code changes only after loooong periods of time in huge chunks with changes spreading all over the project(s). That's progress I guess, because not long ago they just put .zip archives on some network share. Still, merging is a nightmare - and frankly I've had enough of it. And I'm also tired of talking and explaining and begging. This just has to stop - without me constantly being "the bad guy".

My solution:
Since there seems to be no awareness of and/or no interest in the problems and I cannot expect any efforts to last longer than a few days ...strike that, hours, I'd like the subversion server to do the nagging.

My question:
Am I way off-base here or am I looking at the wrong problem? It seems like I'm missing something, and I think I'm asking the wrong thing by looking at tools to solve my problem.

Should I be looking for a tool to solve this problem or what is it I should do to fix this?

Answer 1

You're looking for a technical solution to a human problem. That rarely works.

The reason for that is because if team members do not accept something (nor understand the implications), instead of following the rules, they'll attempt to circumvent them. That's exactly why, for example, developers should accept and understand style rules instead of just being forced to comply by a checker.

Here are a few approaches I either used in the past or have in mind without actually having an opportunity to them in practice. Some may not apply to your case, depending on the position you have in a team (if you're a team lead with excellent reputation, chances are you'll have a better opportunity to enforce your view than if you're an undergraduate who just joined a team for the duration of your internship).

1. Discuss the issue with your coworkers and explain the consequences of large commits. Maybe they simply don't understand that complicated merges are a direct consequence of rare commits, and than small, frequent commits will make merges (relatively) easy.

   I knew a lot of programmers who were simply convinced that merges are always complicated. They did at most one commit per day, avoided to use powerful tools such as Visual Studio's diff and auto-merge, and had a poor practice of manual merging (unless “Take mine” with no further diff inspection is actually a good practice). For them, this had nothing to do with them, and was the inherent nature of a merge.

2. Give concrete examples of what is happening in other companies (especially the ones your coworkers have a deep respect for). They may simply be unaware that it is an issue, and be convinced that a maximum one commit per day is what every team does.

   Some people are unaware that there are teams of 5-10 members who make up to 50 pushes to production, which translates into an average of 5-10 commits per day per person. They may not understand neither how is it possible, nor why would anyone do it.

3. Lead by example. Do enough small commits yourself. If possible, do a short presentation showing their and your merges side by side over a week (I'm not sure if extracting this sort of information is easy from a version control). Emphasize on the eventual mistakes they've done during their merges and compare it to the number of errors you've done (which should be close to zero).

4. Use the “I told you” technique, when appropriate. When you see your colleagues suffer over a painful merge, loudly comment that small, frequent commits could make merges (relatively) painless.

5. Explain that there is no minimum duration to make a commit. A commit may even correspond to a minor change made in a few seconds. Renaming a file, removing an obsolete comment, correcting a typo are all tasks which can be committed immediately.

   Programmers shouldn't fear doing a tiny commit, but rather aggregating many changes into one huge commit.

6. Work with individuals instead of a team, when appropriate. If there is a person who particularly refuses to do frequent, small commits, talk with this person individually to see why is he refusing it.

   They may give perfectly valid reasons which may give you the hint about what's going on with a team. Some reasons I've heard myself:

   • “My teacher/mentor told me that the best practice is to do one commit per day.” It doesn't surprise me, given what I had to hear from my teachers in college.

   • “My colleagues told me that I should make less commits.” I've been told that too in some teams, and I understand their point. We had a log which was practically filled with my commits (not hard to do when four teammates don't even do one commit per day), which frustrated my coworkers.

   • “I thought small commits make it difficult to find a revision.” Somehow valid point, even when the team puts an effort into writing descriptive log messages.

   • “I don't want to waste too much space on our version control server.” The person obviously doesn't understand how commits are stored (nor how cheap the storage space is).

   • “I think a commit should correspond to a specific task.” Given that often, a task corresponds to some work to be done in one day (such as in visual management's task boards), this is not a coincidence. The person should then learn to make a difference between a task in a backlog (2 to 8 hours of work) and a logically isolated change which should be committed (a few seconds to a few hours of work). This is also related to point 5.

7. Search for the reason the team is not doing commits more frequently. You may be surprised by the results.

   Recently, I mentioned in a different answer that speed of a commit matters, and even hundreds of milliseconds may push developers to commit on less frequent basis.

   Other reasons may include:

   • Overly complicated rules to write a commit message.

   • The rule which forces the developer to link the commit to a task from a bug tracking system.

   • The fear of breaking the build.

   • The unwillingness to deal with a risk of breaking the build right now: if you do a commit on Friday evening just before leaving, you can postpone dealing with broken build until Monday.

   • The fear of doing a merge.

8. Determine whether developers understand that there are other benefits to commit often. For example, a Continuous Integration platform is a huge incentive to have frequent commits, since it allows to pinpoint precisely where the regression was introduced.

   I would rather prefer CI platform telling me that I broke the build in the revision 5023 which consists of a change in two methods in one file I did fifteen minutes ago, rather than in the revision 5023 consisting of changes which span four dozen files and represent 13 hours of work.

Answer 2

An organization I contracted for in the past wanted to solve this same problem, and came up with a fairly good social solution: developers do not have their own computers. The development TEAM has computers, but any individual can be asked and expected to work on any development computer on any given day. So, checking in is the only way to make sure you can continue working on what you were doing yesterday!

Management then went around and surreptitiously reverted changes on computers after hours so that anything not checked in was lost. These "simulated computer failures" only had to occur a few times before the devs got on board.

Of course, it's important to explain the "why" of rules as well as the "what". Unless the "why" is made clear, they could just store their source on USB drives or something.