Source Code Control

The next section of the book is all about source code control. The authors start this section of with some hard truth: “One of the important things we look for in a user interface is the UNDO key — a single button that forgives us our mistakes. It’s even better if the environment supports multiple levels of undo and redo, so you can go back and recover from something that happened a couple of minutes ago.” Haha and they are indeed very right! How far would we come nowadays without undo functionality, in any kind of software. Imagine what programming had to be like back in the day when you needed to write it down on paper and then hand it in to some operator. When you made a mistake you had to erase that and hopefully she, yes probably a she, would make sense out of the mess you made.

But source code control systems are about more than undo and redo. They preserve history not for a couple of minutes, but for the entire duration the project is alive. If used correctly, you can go back to what-ever state you desire from last week, month or year. So source code control systems allow you to take undo and redo to the next level.

It does also provide the users with lots of insights since it tracks changes. So you can compare one state to another and see exactly what has changed between them. If you have ever done pull-or-merge requests you know exactly what I mean. When merging you can see the diff between two branches of the source code.

But not just the collaboration is a big plus, also the metrics you might be able to extract from it. For example, using source code control, you are able to find out where hotspots are in your source code. These hotspots are the files that change often. From that you can draw conclusions if that’s just the way the code is designed, or if there is a design problem why certain files get touched in every pull-request. This is really valuable information and this wasn’t really possible to this scale and granularity before source code control systems.

And of course the collaboration and release aspect of source code control is very important. With source code control you can manage what code gets released by simple branches. Often there will be like a production or master branch, a development branch and some open feature branches and maybe even an QA branch. Over the past 5 years or so, trunk based development has been becoming more and more popular again. Trunk based development is where you only have 1 branch, master. You always commit and push to this branch and never branch out. Although this works perfectly well in, let’s say, traditional code bases, like web-apps or microservices. It might not really work for games since well, manual testing is still required. There is no clean way to test if graphics aren’t glitchy, colliders are not working, shaders are missing. This involves manual testing and for that you often create different branches for specific feature builds. But in more business oriented software, which is simply.. well code. You can automate all that and thus you can take more advantage of trunk based development. If you want to learn more about trunk based development I encourage you to read the Continuous Delivery book by Dave Farley. It’s an amazing read!

And the last thing about source code control systems is that you are able to manager your releases better. In GIT you have the capability to tag a certain commit. So you might tag some random commit with a semantic version of “1.0.0”. I won’t go into the workings of semantic versioning, maybe that’s a topic for a blog sometime. But anyhow, you can now, for as long as that tag exists, go back to that random commit by checking out a more remember-able name: “1.0.0”. So by just by saying ‘git checkout 1.0.0’ you will have checked out that random commit. You probably already knew this but that’s cool right? You can also hook up your build pipeline to source code control systems. So when a merge to master is successful, or when a tag is created you kick off your build pipeline and within let’s say 35 minutes your new build is there automatically, compiled in the background. If you have not, take a look at Unity’s build-in cloud build web service! Or maybe even the Unity Build server!

Ok, now the trick with source code control is to always use it. Let me repeat that: Always use source code control! I cannot tell you how many times I’ve seen forum posts, or posts in slack or discord of people who are trying to revive their files because they didn’t use Git. If you are lucky, some IDE’s actually keep local history of all your files; like JetBrain’s IDE’s, or maybe if you have stored your files on some cloud storage you might be able to get them back because they keep history. But this is nowhere near as powerful as just having your files in git. So they authors really drill down on the advice to always use some form of source code control. And I’ll extend that and say, always use Git. Because that’s the industry standard.

Now, I hear you saying, what about Plastic SCM!? And yes, you are right. For large projects you might want to use Plastic SCM. But for the majority of Unity devs around, Git, maybe with Large File Support (LFS) enabled is perfectly fine. The fact remains that you should use some form of source code control; so if you are thinking about using Platic SCM or Git, you are definitely on the right track. The trick is now to choose one and use it as soon as possible.

But my team isn’t using source code control

But what if your team is not using any form of source code control. Well I would sacrifice a raw meatball for each member of the team and then pray for the spaghetti monster to smite them by slapping them in the face one by one with it’s floppy tentacles. Nha, jokes aside. What would you do!? David and Thomas say the following: “Shame on them! Sounds like an opportunity to do some evangelizing!” Haha. Yeah, you really need to do some evangelizing! Just like Obi-Wan, take the high ground and introduce them to source code control systems and teach them how to use it. Organize lunch and learns, or some other kind of light weight training. Maybe even involve people higher up in the company since source code control will save you a lot of grief, time and money. Business people will see the benefits of using source code control, once you explain the concepts to them. And don’t forget the mention that source code control is FREE software. Maybe the hosted versions are not free, but if you want to host it yourself, it is definitely free.

#end

01010010 01110101 01100010 01100101 01101110