Five wrong things to do with version control systems

Here are five wrong things that you can do with a version control system.

1.  Not use a version control system

Not using one, obviously.  The whole idea of a version control system is to allow you to do your work without worrying out backing up working code or figuring out when something stopped working. 

2. Not check-in each change individually

When you use a version control system, it is a good idea to check-in each change and not bunch together changes. This allows you to revert specific changes if they do not work, as well as leaves a history of changes which are easy to understand.

3. Check in generated (compiled) code

Not a good idea to check-in compiled code like java classes or jar/war files.  Or for that matter IDE-sepcific files like .classpath, .settings, .project, etc.  The latter usually contain machine-specific entries like "E:\lib\mail.jar".   Does that mean each develop have his/her own copy of IDE settings?  Yes, unless the settings have no machine-specific information. 

4. Check-in without proper comments

What is a check-in without a proper check-in comment?   Comments like "Checked in", "working", "Committed" are useless and is worse than not putting a comment!

5. Do a demo from a code not in version control

Developers sometime share build with QA.  These are usually from their own systems.  The issue with this is they may have local changes not checked-in.  This can lead to integrity issues.  It will work on the developer's system, but not on a clean setup.

Bonus:

Checking in the sources of libraries, where you are only looking to use the library file as is (for instance "jar" files).

And hey, I am not getting into not having a build script, as part of a project, in version control.

Comments

Popular posts from this blog

Opening a safe deposit locker in SBI

Opening a Kannada Word document

Automating a cordova ios build