Git Outta Here

I’m certainly not in love with Git. I’ve used far too many other types of nicer repos over the decades, but if you are going to use it, you need to use it properly.

At the high level, you have code that you packaged and released. Sometimes you need to just make a simple fix to that ‘exact’ code.

You need to ensure though that the code you are working on is exactly and only the code that you released. If your work habits or environment are messy, that is a difficult task fraught with a lot of uncertainty. But it does not have to be that way, and it should not be like that. If that happened, it is entirely self-inflicted.

So, a key development task is to ensure that that never happens. That is the primary reason for using a repo. Used correctly, most of them will guarantee that you know and can get a hold of the code that you released.

There are several different families of keeping the code organized, so most of the repo tools support a huge number of options. While that is great, it also opens up a hole for people to wantonly mix and match functionality, which is really bad. You can use a repo like Git to make your life easier, but you can also use it to make life a lot harder.

My advice is don’t mix and match. Pick one of the proper ways to use the repo first, learn it deeply, and then only when you really understand, tweak it carefully. For Git, Atlassian produced git-flow. You don’t have to use their tools, but you should strictly follow the branching model and do it carefully and properly.

For people who think that that sounds like more work, it isn’t. It follows the adage “a stitch in time saves nine”. That is for a little more effort up front, you’ll save yourself a whack load of time later; when you actually have less time than now.

Mixing and matching any sort of optionality is often called ‘going against the grain’, which comes from woodworking. If you sand with the grain of the wood, it will be easier and the results will be better. If you use the development tools properly, within a particular family of usage, they will work far better.

Ensuring that you get the exact code that you released earlier is part of another high-level principle, which is to never, ever, ever release untested code. If you haven’t tested it, you can not release it.

If some code does get released, it is because it was tested first. There are legendary examples of people causing huge problems because they violated this. But it is fundamental to every software release, large and small, critical or otherwise. It is the one rule that you should never violate. And if you violate it, it should not be accidental, but rather for some scary reason you needed to take that risk, and you were aware of the risk that you were taking. Accidental release or rollback of code is so easy to avoid, that any sort of excuse is lame.

If you can ensure that the code you released is easily available, then you can ensure that the code you are testing is also easily available. Your testing environment is akin to production. It is just another place you release stuff. In fact, every environment is just another place to release stuff, including development ones. The only difference with development is that people will change things directly, then retest.

If you get those types of guarantees then your repo tool is doing its job, working correctly for you. If you are not getting those types of guarantees, you need to fix your environments, they are broken. The mess is just making your life harder for no reason.