Are SCM check-out’s contemporary? 24 March 2014 Daniel-Fisher-(lennybacon) Article, Project, Tools, Life, ALM My VCS story began with Microsoft Visual Source Safe. I was happy... I had my files versioned. I could view differences in file versions. I could restore previous versions. I could view the history of a file. ... until the IDE started to crash, I had corrupted files and so on. http://www.flickr.com/photos/nesster/5823554695/ So I gave CVS and then SVN and TFS a try. I was happy... I could work with branches I could version source code “over HTTPS”. I could view file versions over HTTPS. ... until I saw a GIT introduction on the .NET Open Space presented by Alexander Groß. I was shocked about how I had worked before! He showed that it is not necessary to explicitly check-out and check-in files. I almost all areas of software development we try to align with business and to focus on the features that help or supports users or customers at their processes (E.g.: OOD, DDD, etc...). So why should I commit a change set just because I want to rename a file a second time? That is not a feature. It’s not even the result of a refactoring. Its just to satisfy the tool. Here are a few reasons why: Refactoring is an important part of the process to maintain a healthy and high quality code base. It means changing the structure... Naming I one of the hardest disciplines in software development. I don’t thing it helps anybody when there is an additional burden called the check-in. From my experience It holds people back from improving the code. 2010 I moved into the DVCS world. I started with HG and later moved on to GIT. I am happy... I can focus on the features. The SCM understands branching The SCM understands refactoring The SCM understands merging Last year on the NRW Conf my friend Ilker Cetinkaya held a lecture about commit messages. In his opinion the commit message should tell a story and answer the questions: What, why & how. He sowed really nice examples of commit messages almost equal to a blog post or a developer diary. Focusing on the Feature (LOB) and providing details about the technical realization. Markdown is an ideal format here. I cannot agree more. After the conference we discussed non-feature-commit-messages and agreed there should just be one: “Rechnerwechsel” the German term for “Switching the Machine”. When I join a project of a customer I sometimes still see SCM systems that still require explicit check-ins. My pleading Let developers focus on the features to deliver better results. Everybody has just 100% to give. Don’t take even a few percent of the developer productivity to hassle with a SCM just for the SCM. Version control exists to support people. Not to change the way people work: The motivation and empowerment of programmers has a direct and strong relationship to the quality of the software.