Repeat this mantra daily – “The only
measure of progress is working code in source control”. Until
your work makes an appearance in the one true source of code truth
– the source control repository for the project – it
simply doesn’t exist.
Sure, you’ve got it secreted away somewhere
on your local machine but that’s not really doing anyone else
any good now, is it? They can’t take your version, they
can’t merge theirs, you can’t deploy it (unless
you’re deploying it wrong) and you’re one SSD failure
away from losing it all permanently.
Once you take the mindset of it not existing
until it’s committed, a whole bunch of other good practices
start to fall into place. You break tasks into smaller units so you
can commit atomically. You integrate more frequently. You insure
yourself against those pesky local hardware failures.
But more importantly (at least for your team
lead), you show that you’re actually producing something.
Declining burn down charts or ticked off tasks lists are great, but
what do they actually reconcile with? Unless they correlate with
working code in source control, they mean zip.
- You
shall check in early and check in often. You anger your coworkers
when you check out a file and insist on keeping it checked out
until some future point in time that is measured using variables
that exist solely in your brain.
- You
shall never check in code that breaks the build. If your code does
not compile, it does not belong in the source control
repository.
- You
shall not go home for the day with files checked out, nor shall you
depart for the weekend or for a vacation, with files checked
out.
- You
shall leave a descriptive comment when checking in your code. You
need not include your name or the date in the comment as that
information is already tracked.
- You
shall use the 'Undo Checkout' option if you check out a file and do
not make any changes. It displeases your coworkers when you check
in code that has not changed at all from the original.
- You
shall not use comments to 'save' defunct code. Fear not, for the
code you delete still exists in the source control code history and
can be retrieved if needed.
- You
shall use source control for more than archiving just code. The
source code control repository makes an excellent storage for
technical docs, SQL scripts, and other documents and files related
to the project.
- You
shall religiously backup your source code control database on a
regular basis and store a copy in an off-site location.
