Code Leader: Using People, Tools, and Processes to Build Successful Software

4.7. Before Committing, Update

Before committing anything to source control, update to the latest code and compile/test. One of the most common reasons that builds fail is because developers don't update to the latest code before committing or checking in their changes. If you don't update before committing, there is no way to know whether or not you are checking in a breaking change. If someone else committed ahead of you, your changes may conflict with theirs and break the build. To keep any changes from conflicting, before you commit, make sure that you have updated to the latest (the tip) in the repository, run a complete build, and passed all the unit tests. Then and only then can you commit your changes and be sure that you haven't broken anything. This process is illustrated in Figure 3-1 in the preceding chapter.

Some source control clients will enforce this rule for you, but others will not. Most systems will prevent you from committing changes to individual files that haven't been updated, but they won't prevent you from committing changes to the repository when other files in the repository have changed.

This is probably one of the rules that is most often flagrantly disregarded. Developers may just forget, or be in too much of a hurry, or not bother to follow the right process. This can be particularly problematic if your build or unit-test process takes a long time or is hard to use. If it takes 20 minutes to do a build of your system and another 30 to run the unit ...