Why Git is indispensable, GitHub or GitLab, and how keys work

There is a question everyone asks when they start working in a team, and the answer they almost always get is wrong: "what is Git for?"

The answer you hear is "to save versions". It is true but useless, like saying Unix is for opening files. The real reason is something else, and the first to understand it was whoever worked in large groups: without Git you do not know who changed what, when, and why.

This article covers three things that belong together: why version control is indispensable, the difference between Git and the platforms that host it, and how public and private keys work. Plus a bit of history, because dates matter there too and it is easy to get them wrong.

Why Git is indispensable

Three reasons, in order of importance. The first one saves your work, the third one makes you good at what you do.

1. Rollback becomes a question, not a drama

The concrete case: a release goes wrong in production. What does a team with Git do? It goes back to yesterday's version with one command and reads what changed between the two.

Without version control, the same question means hunting for an old copy on a hard disk, hoping someone had kept it. The difference between the two situations is not the time saved: it is that one is a procedure and the other is an event.

And a mistake is not a rare event. A file modified while you are inside a machine in production, an edit not yet finished when you need to relaunch, a command that overwrites a configuration file. These are all things that happen, and each one requires a recovery.

2. Context travels with the code

One of the less obvious consequences of Git is that commit messages tell you why. The code says what changed, the message says why it changed.

When in six months someone reads that line and thinks "but why was it done like that?", the answer will be in the history. Without Git that why is lost at the first refactor, the first freelancer who leaves, the first ten-line summary. In large organisations this is the difference between a repository that maintains itself and one where every change means asking someone.

3. Non-linear work becomes possible

This is the technical reason, and it is what makes Git different from everything that came before.

In Git a branch is just a reference to a commit. Creating one costs nothing. The file that holds it is one line of text. This means you can have a hundred different versions of the code on your computer at no cost and without conflicts, and you can move from one to another in microseconds.

Look at the cost of the equivalent concept before Git:

# CON GIT: il branch è un file di testo, si crea in una frazione di secondo
git checkout -b correzione-pagamento

# SENZA GIT: il branch è una COPIA DELLA CARTELLA
cp -r /srv/progetto /srv/progetto-pagamento-bello
# e da quel momento i due sono due progetti diversi, e devi ricordarti
# di sincronizzarli a mano, per sempre

The reason Git was born is exactly this, and I tell that story in the history section: Linus Torvalds needed something that did it quickly, and no free tool did.

What Git is not

It is worth saying, because confusion costs time.

• It is not a backup. The repository is on your machine. If you lose it, you lose everything, and no server knows. Backup is a different thing, and it has to be set up separately.

• It is not a copy of the project. A commit is a snapshot of the tracked files plus the rest.

• It does not protect you from an attacker who has access to your account. If your token is compromised, the attacker can write to the history with your credentials. Signing (see below) is the defence, not the fact that the profile "was private".

GitHub or GitLab: the difference nobody explains to you

The first misunderstanding is already in the question, so it has to be cleared up first.

Git is the program. GitHub and GitLab are services that host Git repositories.

They are different things, like SQLite and Dropbox. You can use Git without ever seeing GitHub, and you can host your repositories on your own server without either of them. Every site that uses Git — GitHub, GitLab, Bitbucket, Codeberg, SourceForge — speaks the same protocol and uses the same program on your side.

This means one very important practical thing: the repository does not belong to the platform. Your code is yours, and you can take it anywhere you like with a git clone. No platform has power over your work beyond the legal power of whoever hosts the service.

The real differences are others.

The two bold rows in the table are the two that matter, and they are the real answer to the question.

GitLab is easier to install yourself. It is not a service you can "pick up and run" in an hour: it is a set of components that talk to each other. But it is designed for that, and the free edition has the features most teams need.

The GitHub code is open but the platform is not. The site is proprietary, and since 2018 it belongs to Microsoft. On GitLab the Community Edition is MIT licensed, and Enterprise is source-available: you can read the code but you cannot redistribute it. The difference is subtle and should be stated precisely, because "GitLab is open source" is true only for one part.

One thing worth knowing, which neither of them highlights: GitHub became enormous. It passed one billion repositories, and in 2018 it suffered the third largest DDoS attack in history, with 1.35 terabits per second of incoming traffic. The name of the billionth repository says the rest on its own.

The practical choice. For a personal project or a small team, GitHub is enough, and not for the sake of the ecosystem but because that is where the people and the tools are. For a company that cannot send its code outside its own servers, self-hosted GitLab is the only serious one of the two options. They are not in competition: they are two trade-offs.

Public and private keys

Here is the part that dismantles the most widespread misunderstanding, and it is worth doing properly because it is the heart of authentication.

The problem they solve

Symmetric cryptography is ancient and has one flaw: the two parties must share the secret first, and carrying it to each other in a way that nobody can read it is exactly the problem you wanted to solve.

In 1976 Whitfield Diffie and Martin Hellman propose the idea that changes everything: two people who have never met can establish a shared secret without transmitting the secret.

The mechanism, in practice

Public and private keys are linked by a mathematical relationship. The trick is that the relationship is easy in one direction and impossible in the other.

# GENERAZIONE DELLA COPPIA. La chiave PRIVATA non esce MAI dal computer.
ssh-keygen -t ed25519 -C "manuel@cyberonions.it"

# Genera due file:
#   ~/.ssh/id_ed25519       -> CHIAVE PRIVATA. Segreto assoluto.
#   ~/.ssh/id_ed25519.pub   -> CHIAVE PUBBLICA. Si dà a chiunque.

# L'unica cosa che dice il file pubblico:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... manuel@cyberonions.it

Here is the point, which is the whole matter:

• the public key is distributed openly, even on a little card, even in an email;

• the private key stays on the computer, protected by a passphrase;

• what is encrypted with the public one can only be decrypted with the private one.

Three uses, and they are all you need:

Hence the name: public because you publish it, private because you never show it. It is not a matter of degree of security between the two, it is a matter of direction: one is for showing, the other for guarding.

Why you do not need a password

When you connect a repository to a server, instead of typing the password every time, the public key ends up in ~/.ssh/authorized_keys on the server. From that moment your private key proves who you are.

The advantage is not convenience, it is that a key cannot be guessed and is never transmitted. A password crosses the network a thousand times; a private key never leaves it.

The connection with Git, which is the operational part

Git does not force you to use SSH: it works with HTTPS and tokens. But if you use SSH, the mechanism is exactly this.

And here is the point almost nobody explains, which causes the panic of every beginner: commits do not travel with your cryptographically signed identity.

# Il nome e l'email nel commit sono DICHIARATIVI. Chiunque li puo' scrivere.
git config --global user.name "Manuel"
git config --global user.email "manuel@cyberonions.it"

# La chiave SSH firma il TRAFFICO con il server. Dimostra chi sei a LUI,
# ma non firma il contenuto del commit.
git commit -m "corretto il calcolo del totale"

This distinction is the reason why the Git history is not signed and must be treated as an unauthenticated document. Anyone who can write to the repository can write a commit with a name and an email that are not their own.

The defence is commit signing: you sign the commit with the private key, and the signature tells the reader "this content belongs to whoever claims to have written it". It is the thing that distinguishes a repository you can trust from one where you have to trust the promise of whoever maintains it.

git config --global commit.gpgsign true
git config --global user.signingkey "YOUR_KEY_ID"

And if the history is already compromised, it is not solved: rewriting history is possible (git filter-repo) but it changes every hash and invalidates every signature. That is why prevention is worth more than any repair.

The history, which is more interesting than it looks

1991-1998: version control was a central server

Before Git the model was client-server. SVN, CVS and the others had a server that was the source of truth, and every developer had a local copy that they synchronised.

The model is simple to explain and has three problems that became unbearable when teams grew:

• if the server is down, you do not work;
• every operation is a network communication, and the network is slow;

• every change needs permissions and locks, and locks create conflicts between people working on different files.

2002-2005: BitKeeper, and the break

The Linux kernel was so large that something different was needed. From 2002 its development uses BitKeeper, proprietary, with a free licence for the kernel.

In 2005 the licence is revoked. The copyright holder, Larry McVoy, maintained that Andrew Tridgell had created SourcePuller by reverse engineering the BitKeeper protocols. The fact, however, is the revocation.

At that point Torvalds is faced with a choice: the Linux kernel, and his ability to coordinate hundreds of developers, depends on a proprietary tool that can close the door at any moment.

The same episode gives birth to Mercurial, which is in the minority today but still used, above all by those who want the same idea as Git with a simpler licensing model.

3 April 2005: Git is born

Torvalds did not want to wait for someone else to solve the problem, and he did not want to argue about licences. He writes his own.

His three design criteria are the interesting part, because they are exactly the answer to the three problems of the client-server model:

• take CVS as an example of what not to do: when in doubt, do the exact opposite;

• support a distributed workflow, like BitKeeper;
• very strong safeguards against corruption, accidental or malicious.

And the criterion that made the project feasible is a number: an application that took 30 seconds to apply a patch and update the metadata was too slow. His requirement was three seconds. Because in the kernel, synchronising with other maintainers could require 250 such operations in one go.

These criteria excluded all the version control systems in use at the time. Nothing existed that satisfied them: hence the decision to write one.

The timeline is incredibly fast:

• 3 April 2005: development begins;
• 6 April: the project is announced;

• 7 April: Git is already self-hosting, the project's repository is versioned with Git itself;

• 18 April: first merge of more than one branch;
• 29 April: benchmark, 6.7 patches per second on the kernel tree;
• 16 June: Git manages the 2.6.12 kernel release.

From the start to the kernel release in eleven weeks. On 26 July 2005 Torvalds hands maintenance over to Junio Hamano, who looks after the 1.0 release on 21 December 2005.

That self-hosting on the second day is the detail worth noting: Git was born with its own repository on Git. A choice that says more than any document about the project.

The name

Torvalds said clearly that he had not looked for a neutral name:

"I am a selfish bastard, and I name all my projects after myself. First 'Linux', now 'git'."

In English git is an insult, an unpleasant or stupid person. The manual page describes it as "the stupid content tracker". The README gives five alternative meanings, and the two most quoted are the acronym Global Information Tracker and Goddamn Idiotic Truckload of Shit. The source calls it "the information manager from hell".

The credit goes to Torvalds himself: he named something that creates problems with the name of the problem. It is the kind of humility that makes the name easy to remember.

1973-1977: RSA, and a twenty-five year secret

The story of public keys starts before Git, and it has a detail almost nobody knows.

In 1973, at the GCHQ laboratories — the British signals intelligence agency — the mathematician Clifford Cocks develops a public key system equivalent to RSA. It is secret, and it remains secret for twenty-five years. The document is declassified in 1997.

In 1976 Diffie and Hellman publish the idea of the public key, but without a working one-way function: the difficulty of factorising had not yet been studied.

In 1977, at MIT, Ron Rivest, Adi Shamir and Leonard Adleman publish what they call RSA, from the initials of their surnames. They work for a year on a function that is hard to invert: Rivest and Shamir, computer scientists, proposed the candidates, and Adleman, a mathematician, found their weaknesses. They also try other approaches, including cryptographic knapsack.

The fact to know is that it was not an isolated case: RSA had been invented twice, and one of the two remained secret. That is why cryptographic security cannot be built on the idea that whoever thought of it first thought it through properly.

Today RSA is used with 2048 to 4096 bit keys, mainly for signing and for encrypting symmetric keys, not data. For data, symmetric cryptography is used, which is faster. The security of RSA rests on the difficulty of factorising the product of two large prime numbers; a demonstrated attack concerned an 829 bit key in 2010.

And there is a note that matters to anyone assessing future threats: Shor's algorithm, on a quantum computer, would break RSA efficiently. It is not a problem today, but it is the reason why the move to post-quantum cryptography exists.

Two Git dates that the trade knows poorly

2017, the SHAttered attack. Two researchers demonstrate a practical attack on SHA-1, the hashing function Git used internally to identify commits. Git was modified to use a resistant variant. For Torvalds the response was that SHA-1 was mainly needed to protect against accidental corruption and that real security lies in signing, elsewhere.

2015, CVE-2015-7545. A vulnerability that allowed arbitrary code execution, exploitable by convincing someone to clone a badly built URL. It is the reason why you never clone a repository from strangers on a work machine.

The rule we follow

CYBER ONIONS's reasoning on all of this is short:

The repository is the thing you do not want to lose. Everything else is rebuildable.

Hence three practices we follow every day:

• the repository is not the backup. If the machine dies and there is no copy elsewhere, the work is lost. What is on GitHub or GitLab is a copy; if the code is secret, it is the only copy and must be treated as such.

• no secrets in the repository, for any reason. A .env file committed by mistake stays in the history forever, even if you remove it afterwards. The .gitignore has to be in place before the first commit.

• private keys do not travel. The private one stays on the machine, the public one everywhere else. And the signing key is not the access key: keeping the two separate is one of the basic good practices.

The underlying reason is what we already wrote in Open source: why it beats paid software: if you can read the code of something you depend on, that thing is not only yours. The open repository is the first step, and the signed history is what makes it verifiable.

If you remember one thing

Git is not for saving versions. It is for knowing who changed what, when and why — and when the moment comes in which a question has two possible answers, that is the only thing that saves your work.