Hi everyone, and welcome to our new screencast about Git core concepts!

I'm Christophe, but I should stress that this entire course was created by Maxime Bréhin, my friend and business partner. But until he feels comfortable enough recording in English, I'm stepping in his shoes for our English versions.

In this first free course, you'll walk through the core concepts that are essential to a good understanding of Git. We'll cover Git's architecture, zones and useful terminology, and explore how its internals go through the creation of a commit and a history of commits.

I’m pretty sure that even if you think you know all this, you'll learn something still!

Why manage versions?

Let’s start with the philosophy of version control systems, focusing on what we, as users, expect from such tools.

The main idea is that we want to be able to browse former versions of our work to figure out what we did since then, so for comparison purposes.
The very notion of archiving copies means we backup these copies. We should then be able to rollback to an earlier version if the current one isn't useful anymore.
Besides, by freeing ourselves from the requirement of a linear history, we gain the freedom to explore new leads, experiment new approaches, switch between ideas, all without losing any of our work or getting mixed up.

These are still all benefits for a single person, a single workstation.

When it comes to collaborating on a project, our expectations grow as we want to share and collaborate with maximum efficiency, that is, with the least amount of friction. We don't want to worry about…

  • who shared stuff first, 
  • who's working on a file we want to work on too (please save us from the old trope of network-stored Word docs that tell us we have to open it read-only because someone else is working on it)
  • how to reconcile and merge files modified by multiple people concurrently; typically, if my colleague tweaked the header and I the footer, the system should merge such edits smoothly on its own.

Doing backups: okay, but beware!

As we just mentioned, Git saves the project. But careful about this perspective: if you look at Git mostly as a backup system, this will likely wreck the quality of your version history and lure you into bad habits.

Such lousy commits are hard to analyze and reuse; as for over-frequent “pushes,” they‘re a waste of time and inevitably lead to unnecessary conflicts.

Do keep in mind that the ultimate goal of version management is to streamline your project workflows.

There are a ton of dedicated backup tools that will do a lot more than Git on this front, and usually back your machine up in the background, continuously and unobtrusively.  For instance, at Delicious Insights we roll with Backblaze.

The main takeaway is this: crafting meaningful commits and only “pushing” when necessary are key to a good project management workflow.

Version management systems: a quick history

Let‘s now look at how version management systems evolved over time to better suit our needs.

In the beginning were the good'ol' manual backups, with timestamped directories and all. The most “serious” users even made a Zip file out of these.

  1. Then came the first version management tools, that helped us store these backups in a central location, so sharing them was easier.
  2. The main drawback of this was that we absolutely needed network connectivity to work.
  3. This led to the advent of distributed tools that let us work even without a network, possibly even without the concept of a server, by storing versions locally too.

Distributed version systems have several major benefits.

First, the server doesn’t need to be reachable at all times anymore.  Should the server go up in flames, we can still work, even collaborate as a team, from machine to machine, peer-to-peer style. It's also easy to put a new server up as the entirety of versions is restorable from the various machines: nothing is lost.

The second main benefit is that we don't even need the network connectivity at all, as most operations are local. The classic scenario is that the company's network falls down: we don't have to put every project contributor on idle, as they can keep working locally on their own machines, committing, branching, tagging and all!

A significant positive side effect of this architecture is how fast most operations are (e.g. commits, logs, resets) as they only happen locally!

Finally, know that not all local work needs to be shared upstream: you can absolutely do “private” work that doesn't go out and pollute the shared work pool your collaborators interact with. This also means you can do a lot of versioned work without having commit rights on the upstream repository.