Check in early

Written 11/2/2017

The Wrong Way

Many developers wait a long time, before they do a check in in the version control system. The reasons are, that they do not want unfinished code to be part of the revision, they haven't finished the feature or they just want to add one more file with one more method before checking in. So.. I say they wait a long time. By long time I mean more than a couple of hours. As I see it - and I am quite clear on that - a software developer should provide several check-ins during a normal day. I have often seen check-ins with more than five files involved. Sometimes there could be a reason for that, such as nuget packages being updated or similar. - but in most cases it would be possible to split up in several small check-ins. Large check-ins with multiple files and many hours of work are dangerous. They are dangerous because it is difficult to have a full overview of the impact in the entire project, and it is dangerous because it can be very time consuming to find defects caused by the check-in. Finally it has big consequences to go back to the previous revision.

The right Way

I strongly recommend very small fragments being checked in, and doing check-ins very often.
As soon as you have added the smallest minimal change, you should ask yourself, if you should check it in. Not that you should check in a single line of code, every time a line has been written, but even refactoring a single file can be divided into several check-ins.

Why? Well, it takes a few seconds to do a check-in, and if you do it in small portions, you can have a nice meaningful description for each of the check ins.
As an example we could imagine that I have removed refactored a class. I have refactored unused namespaces, changed some variable names to follow naming conventions defined by my team, removed a few unused variables and refactored a method, so that it has a better performance, by using fewer requests to the database.
With the use of a single check-in, my check in comment would probably be something like: "Refactored class", while if I had several check ins, the check in comments could be:

  • Removed unused namespaces
  • Changed variable names to follow naming convention
  • Removed unused variables
  • Optimized SomeMethodName by using fewer database requests

So... the revision check in comments can nearly be read like a piece of lyrics (just as you can do with elegant code:)). And the great thing is, that if I found that the method I refactored caused something to break in my software, I would know exactly which revision to look into. Even better it is, if another developer should fix a defect half a year later, caused by this exact revision. The developer would probably use a lot of time, if he found that the defect was caused on a specific date, where he found only one check in with 100 files changed, while it would be a lot easier for him, if he found several check ins, with great descriptions for each check in. Quickly he/she would be able to filter out several check ins and narrow down the files to be relevant for fixing the defect.

Conclusion

Check in often. Especially if you add new files. Check in as soon as you have added the file. Communicate to your team, that you have added a new file, so that they know, that the file has been added, but also the project file has changed. Then you can start working on the file afterwards. Your team will know, they should take the latest revision before they add new files, or do any other changes involving the project file. We do not want several developers working for a long time, all doing changes to the project file. We simply do not want to waste time on synchronizing. It is waste of time, and it does not give our business any value at all, that we need to spend several hours on synchronizing, as a result of many developers changing the same file at the same time. Check in, check in, check in and communicate, communicate, communicate.

Software teams with a great check in strategy and great communication, can nearly avoid any synchronizing issues. Lots of hours gained, and lots of value added to the business instead, and the best part... you can use your development time on something, which is much more exiting, than solving a complex synchronizing issue.