Learn system design from Git - Evolutionary Architecture
Last updated
Was this helpful?
Last updated
Was this helpful?
Like most people I heard the super hero story about how Linus Torvalds wrote Git in four days. We all like creation stories, donāt we?
The story was definitely incomplete. It seemed Linus did write the core Git functions in a few days but that was not the Git we are familiar with. The early version of Git was notoriously hard to learn and hard to use. It was designed for a few specific use cases. The so called user interface was just some shell scripts on top of the core primitives.
But what amazed me was how Git evolved from a specialized version control tool for Linux kernel community, into the best distributed version control system we know it today. Its evolutionary architecture allowed it to iterate rapidly through guided, incremental change across multiple dimensions.
Looking back, we can summarize some important architectural decisions that made Git possible.
Clear, narrowly focused requirements. Git was developed out of a crisis: Linux kernel group needed a version control system and none of the existing systems would work for their use cases. Linus designed Git essentially for himself and the kernel community. He knew exactly what they wanted. There was no product management needed. The customer and developer were the same people. This was Customer Obsession at its extreme.
Clear tenets to guide the design decisions and architecture evolution. Linus called out in his presentation he needed a version control system that is Reliable (with built in content integrity validation), Distributed (optimized for offline mode), High Performance (branch merge needs to be fast), and Tracking Content of the entire project, not individual files. The user interface was not his top concern but he knew user interface can evolve for the better quickly if he got the underlying architecture right.
Agile development process. Linus shipped the Minimum Viable Product of Git in days and within a month Linux kernel was running on Git. A lot of the rich tools and performance optimizations like pack were done much later. He created a fast feedback loops from customers to guide where Git should go.
Understand constraints. Linus knew clearly what he didnāt want - his constraints. He didnāt want Git to be like CVS. He knew Git needed to limit the number of files it could manage inside one repository. Linux kernel at the same time had 20k files and he tested 100k files. But Linus clearly said Git was not designed to manage 1 million files in one repository. The moral: knowing what you donāt want to do is as important as knowing what you want to do, maybe more important in many cases.
The success of Git is an evolution story.
āSome call it evolution, And others call it God.ā - WILLIAM HERBERT CARRUTH