Source Control Management (SCM) is more than just a collaboration tool for developers. Beyond tools such as Git, Mercurial and Subversion, SCM is also a set of best practices that can include the concept of a change lifecycle and a change request system.
Somewhat confusingly, the abbreviation SCM doesn’t just stand for Source Control Management, but also for several other closely related terms that should not be confused, including Source Code Management (from the world of Git), Software Control Management, and more commonly Software Configuration Management. Another common misconception is that SCM is the same as Revision Control. Rather than explaining the difference between all these terms (which is not the purpose of this article) we will focus on Source Control Management, define its meaning, and describe some best practices.
So what are some SCM best practices?
SCM is all about the core project files containing source code, and how these shared files are managed. Source Control Management is a vital system that enables developers to work together on the same development project whether they are in the same room or a continent away. If code gets messy, then SCM allows you to revert to an earlier clean version, which is often the quickest solution to fixing the problem. However, developers working together on a project using the same tools still need a common approach to tool use for best effect.
Simple steps that can be taken to reduce development risk and improve efficiency
- Starting with the basics, choose a source control system.
Keep your source code in source control (but not the files generated / compiled from it).
Ensure the working file is from the latest version of the source file.
Only check-out the file being worked upon.
Check in immediately after alterations are completed.
Review every change before committing. Use the diff function!
Commit often – every commit provides a rollback position.
Make extensive, detailed notes in the check-in comments about why the changes were made.
Developers must commit their own changes only.
Use the ignore button for files that should not be committed, consider adding pre-commit filters to prevent the wrong kinds of file (such as accidental check-ins of personal user settings docs) from entering source control.
Ensure external dependencies are added to the source control! Quite often, everything works great on the contributing developers' system but not elsewhere simply because they forgot to add dependent files to the system.
You might think all these steps are pretty obvious, but you'd be surprised how often these basic steps are missed. This leads to errors and committed files that have no business being in the repository. No matter the SCM system used, these basic steps prevent mistakes and make life so much easier for development team members. Before starting a new project, it is worth recapping these steps / rules with the team to make sure become part of your team's DNA – repetition makes perfect.
Of course when dealing with safety-critical development or larger projects where complete transparency and traceability are required for hundreds or thousands of contributing developers, SCM alone is just not sufficient. An upgrade to a full and integrated Application Lifecycle Management software is necessary to automate many of the steps above, helping to avoid manual mistakes.
codeBeamer ALM Source Control Management
codeBeamer ALM supports all the major DVCS so no matter what your developers prefer (Git, Mercurial, Subversion, or another platform), giving you the freedom that most developers dream of. codeBeamer ALM provides complete Application Lifecycle Management capabilities across the product delivery process, and is designed for scaling Agile and implementing DevOps. It enables your teams to leverage automated testing and maintain control over all processes and changes throughout the lifecycle.