The Game of Git
Table of Contents
Why?
When you play a game (or maybe just older games instead of the F2P crap primarily available nowadays), you would go through the game and have the danger of having to start over again at any time. At some point, developers decided they didn’t want this to be quite so punishing and instead decided to go with the concept of a checkpoint. Checkpoints were great, because now the player didn’t have to play the whole game all over again from the start, including the intro boring tutorial stuff, but could instead start from the most recent checkpoint.
Gamers then were able to use this to their advantage and try some new things. Instead of taking the safest route through the game, they could try something new. They could do something dangerous and see if they could do better in the game by trying something with a bit more risk, because if they died and had to start over, they won’t have to start at the beginning of the game, but instead can start at the most recent checkpoint. I used this functionality to try to defeat a boss with as few consumables as possible, being able to try several times. If I still couldn’t beat it after a few times, I’d give in and use consumables.
But how does this apply to code…?
Interestingly enough, developers have a similar issue. They will work on their project and, as they add new features, they may want to get experimental and crazy and try something that might break other things. But, if it pays off, it could work great! So the problem arises, what if we try this new functionality but it doesn’t work and we break the rest of the app? That’s where git (or source control) comes in.
So, logically, before we try our new, crazy feature, we should create a checkpoint! Right? Can it really be that easy?
Yes. It is. In git, the concept isn’t called a checkpoint but instead is called a commit. Additionally, you want to take advantage of this control and make many commits. My rule of thumb is every time I add some new code and it builds/runs, I make a commit. Even if I don’t know if I’m going to try something new and crazy, I might inadvertently do so and break something I didn’t mean to. So if that happens, I have a very recent checkpoint/commit I can fall back to and make sure that I have something that still works.
Now, the analogy isn’t perfect. Git is inherently more complex than a game save since it’s not particular to a specific game, but can instead cover many more scenarios relating to programming. The good news is you rarely need to step outside the analogy, especially when you’re first starting to use it.
git function/term
game/checkpoint metaphor
add/commit
create a checkpoint
remote
where your cloud save exists
push
save to cloud
fetch
get the cloud save, but don’t use it right away
pull
get the cloud save and use it immediately
clone
copy someone else’s cloud save
checkout
revert to previous save
I’ll add more as I think of them. If you have any suggestions, please add them in the comments!
Now, directly contradicting my previous statement about how you don’t need to concern yourself much with the things that don’t compare to video games, git is actually designed to allow multiple developers work on the same project. The way this works I cannot think of a good comparison to game saves/checkpoints. Just be aware that you have to communicate with your team about how to handle these situations.
How is this useful to me?
Honestly, I don’t think this article will be overly actionable for you if you’re not at least slightly familiar with it already. What you can do, though, is refer to the metaphor table to understand the concept and then google how to do a git pull for example to find the more intimate details.
Why?
When you play a game (or maybe just older games instead of the F2P crap primarily available nowadays), you would go through the game and have the danger of having to start over again at any time. At some point, developers decided they didn’t want this to be quite so punishing and instead decided to go with the concept of a checkpoint. Checkpoints were great, because now the player didn’t have to play the whole game all over again from the start, including the intro boring tutorial stuff, but could instead start from the most recent checkpoint.
Gamers then were able to use this to their advantage and try some new things. Instead of taking the safest route through the game, they could try something new. They could do something dangerous and see if they could do better in the game by trying something with a bit more risk, because if they died and had to start over, they won’t have to start at the beginning of the game, but instead can start at the most recent checkpoint. I used this functionality to try to defeat a boss with as few consumables as possible, being able to try several times. If I still couldn’t beat it after a few times, I’d give in and use consumables.
But how does this apply to code…?
Interestingly enough, developers have a similar issue. They will work on their project and, as they add new features, they may want to get experimental and crazy and try something that might break other things. But, if it pays off, it could work great! So the problem arises, what if we try this new functionality but it doesn’t work and we break the rest of the app? That’s where git (or source control) comes in.
So, logically, before we try our new, crazy feature, we should create a checkpoint! Right? Can it really be that easy?
Yes. It is. In git, the concept isn’t called a checkpoint but instead is called a commit. Additionally, you want to take advantage of this control and make many commits. My rule of thumb is every time I add some new code and it builds/runs, I make a commit. Even if I don’t know if I’m going to try something new and crazy, I might inadvertently do so and break something I didn’t mean to. So if that happens, I have a very recent checkpoint/commit I can fall back to and make sure that I have something that still works.
Now, the analogy isn’t perfect. Git is inherently more complex than a game save since it’s not particular to a specific game, but can instead cover many more scenarios relating to programming. The good news is you rarely need to step outside the analogy, especially when you’re first starting to use it.
| git function/term | game/checkpoint metaphor |
|---|---|
| add/commit | create a checkpoint |
| remote | where your cloud save exists |
| push | save to cloud |
| fetch | get the cloud save, but don’t use it right away |
| pull | get the cloud save and use it immediately |
| clone | copy someone else’s cloud save |
| checkout | revert to previous save |
I’ll add more as I think of them. If you have any suggestions, please add them in the comments!
Now, directly contradicting my previous statement about how you don’t need to concern yourself much with the things that don’t compare to video games, git is actually designed to allow multiple developers work on the same project. The way this works I cannot think of a good comparison to game saves/checkpoints. Just be aware that you have to communicate with your team about how to handle these situations.
How is this useful to me?
Honestly, I don’t think this article will be overly actionable for you if you’re not at least slightly familiar with it already. What you can do, though, is refer to the metaphor table to understand the concept and then google how to do a git pull for example to find the more intimate details.
fetch get the cloud save, but don’t use it right away
pull get the cloud save and use it immediately
Ohhhhh. That makes a lot of sense.