And that's Time.
The picture of an eye with an ancient clock reflecting on it.
Listen to the audio version!
Have you ever found yourself in a Git mess?
If you have a considerable amount of experience in programming and has been using Git for some time, the answer to this question is most likely to be yes.
Due to the existence of many commands and complex rules, a messy Git state can be as hard to understand as a badly written application. Even if you have more experience with Git, it won’t be easy to revert a wrong rebase in hindsight unless you know all the steps that created that mess in the first place.
If you don't know all the steps — say you’re helping somebody else — the easiest approach is to go back and start over. Reset the state to a working commit and reapply all the changes again, preferably by cherry picking each commit from the [git reflog](https://git-scm.com/docs/git-reflog).
In order to fix a Git mess in hindsight, you need to know all the steps that created that messy state in the first place.
Git implements Event Sourcing.
Event Sourcing is the same architecture that powers Bitcoin. You can say a commit stores a "committed" event on a Git repository the same way a transaction stores a "confirmed transaction" on the Blockchain. The difference is that nobody has to wait for the commit to confirm.
Git is like time.
Every time you commit, you’re ticking the clock to move forward.
You can go back to the past by resetting the state to a previous point in time. However, if you change the past and go back to the future, you risk changing the future as a side-effect.
For that reason, if you change the past, Git will have to create a new forked timeline and modify the hash of all the commits since the point you changed. Git will ask you to review all the forward changes to make sure they're still in a valid state. It's a way to avoid a "Temporal Paradox" from happening.
Git's Event Sourcing model is very useful. It makes the system secure and debuggable.
If nobody can change the past unnoticed, that means your code will be safe from malicious changes. If you can go back to the past, that means you can debug the code the first time when the problem was introduced.
Git is like time. If you change the past, the future will be affected.
Git allows high availability.
It affords you to read from multiple remote repositories. Those repositories can be distributed copies of the project so that many people can collaborate through the network.
git fetch sam.git fetch mary.
If one machine is disconnected from the network, either because the developer got hit by a bus or by a 410 GONE, the project will still be available and work will continue.
However, most projects use a centralized service like Github to store the code. They don’t leverage the high availability capabilities of Git. If a centralized server pulls the plug, everybody else has to stop.
git fetch origin.
For many projects, the default origin remote has become synonymous with Github.
Git allows decentralization. However, people insist to use it in a centralized way.
Similar to Bitcoin, Git is a carefully crafted piece of engineering aimed to be decentralized, secure and debuggable. Event Sourcing is the core architecture and a Merkle Tree is the data structure. It uses many fundamentals of how the world works and turns that into an effective Source Control System.
In the past, I've written about The Doctor And The Scalpel. The post tells how developers tend to find problems and blame their tools. However, most of the time the problem is not the tool, but the lack of knowledge of the underlying fundamentals.
Git is a perfect example of that.
If you don’t understand the fundamentals, you won’t be able to make good decisions on how to use its commands and how to reason about its complex rules. Maybe you can memorize what's a git commit, but you’ll be doomed to always find yourself in an irreversible mess the first time you see a code conflict.
Sometimes the best long-term strategy is not to learn how to fix a problem and memorize commands, but have enough knowledge to do it right from the beginning so that you’ll never end up with a mess in the first place.
If you don't, at least the internet has got you covered.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.