I’ll start by saying every programmer should be using source control – even on small personal projects.
I also believe it’s important to commit early and often.
I generally commit several times per day. This is part of breaking changes into small bits. After making each small change, and confirming it works, I’ll commit that change. Depending on the branching strategy your company uses, and the source control tool, that commit might be to a personal branch, or it might be to a shared branch.
Let’s say you’re adding a new report to a program. That might involve ten steps: add a new menu option, display a new screen, display filtering and sorting options, retrieve data from the database, format the data in the screen, etc.
Now, let’s say you decide to wait to commit until you’re done with everything. But, on the seventh step, you make a change that breaks everything. Many of the seven changes you’ve made have probably been in the same file, or same few files. How easy will it be to undo the seventh set of changes when it surrounded by changes from the six steps?
So, I’ll commit after getting each small step to work. Add the new menu option, then commit. Add the blank screen, then commit. Display the sorting and filtering options, then commit. If something goes wrong with the changes for the seventh step, I can instantly “roll back” my code to the working code that existed after the sixth step.
Return to “Life as a programmer outside Silicon Valley” index