Git has become the software industry de facto standard version control system. It was created by Linus Torvalds to support the singular development of the Linux Kernel, however it has been adopted by most open source projects as well as the corporate world. Does that mean it’s the best tool ever?
A bunch of years ago I wrote a rant on my blog about Git. I was frustrated and, honestly, I didn’t want to accept that it was becoming the de facto version control system. My writing style was controversial and kind of sensationalist if you will. It got a lot of criticism, some of it made me realise that my point wasn’t clear, my article wasn’t fair or even useful. Eventually, I didn’t see it as a contribution and some weeks later I decided to remove my post entirely. Interestingly enough I also received criticism for breaking those links pointing to my post, but I certainly embrace the fact that I can change my mind and evolve as a thinker. This is why opinionated articles are better stored on one’s personal blog, because that gives oneself the power to remove or change them, regardless of whether other people think it’s right or not.
Let’s see if I can be more neutral this time, some years after that rant and writing on a site that is not my personal blog.
A recent article from the great Hadi Hariri got some of my friends asking me again about my opinions on Git. They have inspired me to write about it again, so I want to thank them all first.
The nature of the development of Linux is very particular. Contributors from different countries and time zones, many of them have been contributing for free in their spare time. Speaking different languages, spending different amounts of time an energy. Remote, asynchronous. Think of the complexity of Linux, it’s everywhere, on most cloud servers, on most smartphones and tablets… it must be compatible with old versions, open to future versions, compatible with tones of hardware devices from thousands of manufacturers. Under these circumstances, you need an outstanding version control tool, something extremely powerful and flexible. As far as I am concerned, that made Linus come up with Git, a tailored tool to cover the needs of Linux developers.
Linux Torvalds’s code has conquered the world. I can’t think of a programmer with a bigger impact. First because of Linux, later because of Git. Linus is the king. I am a GNU/Linux user since 2000 and I highly appreciate Linus contributions, he is just a genius.
I personally have never worked in an environment that was even close to the Linux kernel. I’ve been crafting enterprise software, vertical business-focused applications, most of my career. I haven’t needed most of Git features.
Git is extremely powerful. As far as I know, the scenario where it’s not capable enough is the development of games, as there are massive binary files that must be versioned. I’ve been told Git is slow for massive binary files.
The winner for huge projects with huge files is Plastic SCM, an incredibly powerful and friendly tool made in Spain.
Yes, there were great alternatives. I loved Mercurial (Hg). I believe those people who say Git is the best VCS ever, fall into one of these categories or both:
With Mercurial (Hg), merging branches was as easy as it is with Git - it was really hard with Subversion (SVN).
The mercurial mental model was simple as the history couldn’t be changed. Whatever you committed to another repository would be there forever. I you wanted to revert the change, you could apply a reverse commit but the history was always kept. Well, there were certain plugins to change the history that I didn’t want to use at all. Most developers would discourage others from using those plugins. Keeping the history untouched was fantastic in my experience. I value simplicity a lot because I make lots of mistakes. Mercurial was simple.
The messages coming from Mercurial where very easy to understand, both the ones coming from the command line as well as those coming from TortoiseHg (GUI). It was very clear when you were going to mess it up, loose changes… Commits couldn’t ever be “detached” for instance. The command line was simple and easy to use, easy to understand and even to remember. I didn’t have the need for aliases in the terminal.
I believe that part of the reason why Git won the battle has to do with service providers. Github beated Bitbucket. So part of the reason is marketing, as usual. Github and Gitlab added another set of tools on top of Git that are very appealing for teams. By the way, in many cases I am finding teams overusing some of those tools, again using the inappropriate tool for a problem they don’t even have.
We like to copy “successful” engineering teams, it looks like everybody wants to be an engineer at Facebook or Netflix and we often copy their practices even if they don’t apply to our context. I am not sure what are we missing here as an industry. Is it education? mentoring? knowledge of the history? critical thinking?
I personally preferred Mercurial for the type of apps I’ve been building. But, Mercurial is definitely not enough for the development of the Linux Kernel. Moreover, Mercurial developers and providers didn’t do as good marketing as their competitors.
Now that pretty much everybody is using Git, I had have to learn Git to help others and myself fix the mess we often create in the code base, sometimes losing work/changes, sometimes redeploying old bugs into production, just because we decide to use a tool that we don’t really want to learn in-depth. Often developers underestimate the power of Git, its complexity and the harm it could cause when you don’t understand how it works. Yes, the problem is not the tool, it’s us people. We like to think that a version control tool should be something easy to use, nobody wants to take an online course on Git, except those who realise they have to. If you drive a Ferrari thinking you are driving a bike, you will be in trouble soon.
I honestly don’t agree with people when they say Git is very easy to use and understand. No, it’s not. It’s complex and still ugly to me, but I embrace the fact that Git is everywhere. It’s the tool that won the VCS battle and I am not going to fight against it forever. In fact I like learning new tools, so when I realised there is no workaround, I started learning Git with joy. It’s all in our mind after all.
As a senior developer, I want to be open minded and accept the reality even if I believe we have chosen the wrong path. It’s the only way to learn from young developers and they often are the most innovative people. The software industry is pure innovation which means sometimes we take unexpected or disruptive roads. I see my senior role as someone who supports others even if sometimes I disagree. I will be happy to give you my opinion if you ask for it, but I will not oppose decisions/trends when the whole team agreed on them or the whole industry decided to go that way.
This feeling that we are complicating our lives more than we need to, comes up with many other technologies. My reaction when I first time saw Flux and Redux, was very similar, I though it was crazy. Then I took some courses, learned how to work with it and I am fine with it but I don’t think is the best solution for all the problems, in fact the whole idea of React, Vue or Angular is absolutely overkill for webs that merely display static info to users.
It seems to me that this is the way we evolve our industry, it’s a mix of marketing, hype, teaks on old ideas, refinements, courage, innovation, failures,… as I get older, sometimes I feel like we are spinning in circles but I accept it.
Whether you like it or not, my advise is to learn Git in-depth. Yes you could learn just “clone, pull, commit and push”, but the reality is that you will need to understand how it works beyond that. You will work with people that value a “clean history”, and will want you to squash and rebase all your commits. Sometimes for good reasons, sometimes because they are just copying blindly somebody else. There will be green field projects where the team will be able to work with a trunk-based development approach, but there will be times when the team wants to use Git-flow - sometimes for good reasons, sometimes because they are copying somebody else.
The command line is not intuitive but most users will prefer it over the GUIs because there is no way those GUI tools could really hide Git’s complexity, so you better know that you do and use the terminal.
Everything we learn and master seems to be easy to do, this is why Git expert users say it’s easy. For someone with no idea of version control systems, or coming from old/proprietary systems, Git is hard to understand. I prefer to tell people it’s complex and powerful and my advise is to read a book or take a good training course if you are going to be using Git everyday.
Answering the headline of this article, I don’t think Git is the best VCS ever for any project. Certainly for the Linux Kernel, it is. I liked it more when you could choose among Bazaar, Darcs, Mercurial, Subversion, and others but that is not the case any more. I would prefer to use Plastic SCM, but for good or bad, everybody uses Git and wants to use Git.
Do you want more? We invite you to subscribe to our newsletter to get the most relevan articles.
If you enjoy reading our blog, could you imagine how much fun it would be to work with us? let's do it!
But wait a second 🖐 we've got a conflict here. Newsletters are often 💩👎👹 to us. That's why we've created the LEAN LIST, the first zen, enjoyable, rocker, and reggaetoner list of the IT industry. We've all subscribed to newsletters beyond our limits 😅 so we are serious about this.
