Git The Big Picture

Table of Contents

1. Training overview
2. Know Git

• 2.1 Version check
• 2.2 Welcome to Git
• 2.3 Upload a project to Git
• 2.4 Create snapshots (commits)
• 2.5 Time Travel
• 2.6 Demo Summary

3. Understanding version control

• 3.1 Follow the history of a project
• 3.2 Manage multiple versions of a project
• 3.3 Share code between developers
• 3.4 Coordinate teamwork
• 3.5 Version Control Summary

4. Understand what makes Git special

• 4.1 Good reasons to use Git
• 4.2 Client-server version control
• 4.3 Distributed version control
• 4.4 Reasons to be careful with Git
• 4.5 Summary of advantages and disadvantages of Git

5. The Git ecosystem

• 5.1 Integrate Git into your environment
• 5.2 A GitHub Preview
• 5.3 The open source workflow
• 5.4 Training conclusion

6. Git Commands Quick Reference

1. Training overview

Hello, I am Paolo Perrotta. Welcome to Git: The Big Picture. If there is one technology that is omnipresent in software development today, it is Git. No matter what programming language or operating system you use, almost everyone uses Git at one time or another.

Git isn’t exactly welcoming when you first approach it. It has many esoteric commands and features, but if you look at the big picture — the big picture — you’ll find that there are a handful of fundamental concepts that are key to understanding Git. And if you master these concepts, you can start using Git today and learn all the intricacies as you need them. You will have a good foundation to build on.

What you will learn in this training

This training is short, but it lays the essential foundations:

• If you are new to version control: you will get a clear idea of ​​what it is and how it works.
• If you already know other version control systems: You will learn what makes Git special and different, including the idea of ​​distributed version control.
• The Git ecosystem: We will also discuss popular Git-based services, like GitHub.

Prerequisites

This training does not have many prerequisites. You are expected to be a software professional or a student on the path to becoming one. You don’t need to be very experienced or even very technical. You might be a team manager who doesn’t necessarily write code. We’ll look at some technical details, but overall everything in this course is pretty high level — conceptual.

• What is Git – The principles behind it – What it can do for you

Training structure

The training is divided into four main modules, all lasting less than 20 minutes. You can watch the entire thing in one session:

2. Know Git

Module duration: 14m 28s

2.1 Version check

Before we begin, a quick version check. This training was created using Git 2.x. The exact version doesn’t matter here, because Git is very stable software — it hasn’t changed much over the years. This training covers general concepts that apply to virtually any version of Git.

There are one or two special cases where this is not entirely true:

• At some point a command will be mentioned that is not available on very old versions of Git — an alternative will be provided.
• In general, don’t worry about the version. Whether you’re using an older version or even a future version of Git, the content in this training should remain relevant.

2.2 Welcome to Git

Simplified definition

Welcome to Git! If you’ve never used Git and don’t know what it is, let’s start with a definition. Git is an open source distributed version control system that… wait, no, that sounds really complicated. Here is a simpler definition:

Git is a tool that tracks changes to source code.

It’s that basic. That’s what he does. It tracks changes to any file, really, but it’s primarily used for source code files. And if you put it that way, it doesn’t seem like much. You wouldn’t think that a tool that tracks source code changes could change your life or the lives of a software development team — but it sure does.

For most software professionals, using Git has many interesting implications that we’ll explore in the rest of this course.

Module plan

This module is a beginner’s course, so we start from scratch:

1. Quick Git Demonstration — The most basic features of Git in practice, so you have something concrete to anchor the next discussion on.
2. Next module — Overview of version control: the idea of ​​tracking changes to source code.
3. Module on Git vs other tools — What makes Git special and different from other similar tools. If you already have experience with version control, this is where the important information for you begins.
4. Git ecosystem module — Online services like GitHub.

All modules are less than 20 minutes, sometimes much less. You can watch this training in one sitting if you wish.

2.3 Put a project under Git

This section provides a demonstration of very basic Git functionality from a terminal window (command line).

Note: If you don’t normally use the command line in your work, don’t worry. The command line is used here to show you the commands and familiarize yourself with Git vocabulary. You definitely don’t need to memorize the commands. You might never even use Git from the command line — you could still use it through a built-in GUI in Visual Studio, for example.

Demonstration context

Consider a directory that contains an open source software project — in this case, a popular JavaScript framework (but the project doesn’t matter). There are thousands of directories and files in this project: source code, documentation, configuration, as in any non-trivial software project.

Initialize a Git repository

To put this project under Git, use the following command:

git init

This command means: put this project under Git. In practice, this creates something called a repository or repo — a Git storage space. For now, don’t worry about the exact location of the repository. Let’s say it’s somewhere on your computer, and it’s still empty because we just created it.

The repository may contain snapshots of your project. Let’s see how it works.

2.4 Create snapshots (commits)

The two-step process

Creating a snapshot of a project is done in two steps:

Step 1: Tell Git which files will go in the snapshot

git add .

The dot . means this directory I am currently in. So we tell Git to include the current directory in the snapshot — all its files and subdirectories, the entire tree.

Important: This command has not yet created the snapshot. It’s just the first step.

Launchpad metaphor (no launch): Imagine that we have a launchpad to the repository. What we just did was place files on this launchpad. This launchpad is also called the index in Git. In this case, we placed all the project files in the index.

Step 2: Create the commit

git commit -m "Premier commit avec tous les fichiers"

git commit means: creates a snapshot that includes all the files I put on the launchpad. We can give a message to the commit to describe what it contains. When we send this command — it’s takeoff! The files arrive in the repository and become the first snapshot of the project.

View history

git log

This command displays the project history — so far it only contains this single snapshot, this single commit in Git parlance.

Create a second commit

A single commit is not very useful. Let’s imagine that we have to do something that happens all the time in software development: fix a bug. We modify a file in the text editor to correct the bug.

Check project status:

git status

Git shows me that this file has been modified — in red. This is already something quite useful: Git tells me which files have changed since the last commit.

Now let’s create a second commit. This time it will only include changes since the previous commit:

# Étape 1 : Ajouter le fichier modifié
git add nom_du_fichier

# Vérifier le statut (le fichier apparaît maintenant en vert)
git status

# Étape 2 : Créer le commit
git commit -m "Correction du bug"

Git shows the modified file as green to indicate that it is ready to go to the next commit. Then, takeoff — we now have a second commit.

git log

We can see two commits: a recent one with the latest modifications, and an older one containing all the original project files. Git also indicates who created these commits.

See the differences between two commits

git diff <identifiant_commit_1> <identifiant_commit_2>

Note: Commits are identified by long hexadecimal codes automatically generated by Git. You don’t need to use the entire code — the first few digits are enough.

This command shows that the only thing that changed between the two commits is that, in this file, this line changed. We can therefore know what changed in the project, who changed it and exactly when. This is already a very useful concept, especially in a large project!

2.5 Traveling in time

One of the most important reasons to use version control is time travel.

Scenario

Suppose, for some reason, we want to revert to an earlier version of the project. There could be many reasons, but let’s say we received a new bug report and realized that maybe the bug fix in the last commit had side effects and caused another problem. We therefore want to find this new bug, and to do this, we want to return to an earlier version of the project — before the correction.

In this demonstration, we only modified one line, so we could undo the change manually. But imagine a real project where a single commit can involve changes to tens or hundreds of lines of code. It would be infeasible to undo the correction by hand.

The git checkout command

Instead, one can use Git with a single command that says: Git, take me back in time to this version of the project.

git checkout <identifiant_du_commit>

checkout takes the version of the project to which we want to go. We copy and paste the commit ID. When we send this command, Git takes the contents of this commit and places it in our file system.

If we edit the file again, we see that the previous modification is gone. The file is returned to its original state. We turned back the clock to the previous version of the project.

We can now do all the tests we want.

Revert to the most recent version

When we are finished, we can resume the most recent commit and move forward in time again:

git checkout <identifiant_du_commit_le_plus_recent>

If we check the file again, our previous modification is back. We reverted to the latest version of the code.

2.6 Demo Summary

In this module, we walked through a demonstration of basic version control functionality with Git:

1. Creating a repository (git init) — Uploading a software project to Git.
2. Creating commits — Two snapshots of the project have been created. Each commit is a different version of the project.

• The first containing all project files.
• The second one containing only a change to a specific file.

3. Viewing the history (git log) — Git can display these two commits and additional information, such as the author name and the differences between them.
4. Time travel (git checkout) — Free movement between the two versions of the project.

Intrinsic value: If Git did just that for us — check the project history and travel to any point in that history — that would already be enough to make it worth our while. But it does much more than that, much more, in fact. Version control is a sea change in software development, and the following module explains why.

3. Understanding version control

Module duration: 19m 5s

Note: This module is about version control in general, not Git specifically. If you are already familiar with any version control system, you can move on to the next module. Maybe just look at the section on managing multiple versions of a project, as a few Git-specific commands are mentioned there.

3.1 Track project history

The most obvious benefit

The most obvious benefit of version control is that it gives you a detailed history of your project. With a long-running open source project, one can see all the changes, their messages, authors and dates — everything that happened.

This can be useful for any type of project, not just software projects. You can even use version control to produce training, for example. In software projects, however, this history is even more important because the source code is so complicated and difficult to manage. A history like that can help you debug your code or roll back broken changes. It’s like having an infinite undo/redo function.

Before version control: the manual method

Before version control, most people did something like this — looking at a very old project (a video game) managed without version control:

• Periodically copy and paste the project folder into a save directory.
• Some directories are named with a date or version.
• Do not delete code, even unnecessary code, for fear of needing it again — the code was simply commented out.

The result? A big mess. We weren’t 100% sure which of these folders contained which, the code was littered with commented functions, and ironically, sometimes we still lost important information because of the confusion between all these copies.

With version control

Today, with all projects under Git:

• To recover an old file or deleted slide, simply go back in time — and that’s it.
• To find out where a change took place, just ask Git.

Warning: Version control is not a backup, at least not in itself. If the repository is on your laptop and the disk fails, you lose both the project and the repository. A separate backup strategy is required. Version control can be useful for disaster recovery in some cases, but in general it is not a substitute for a comprehensive backup strategy — it depends on the exact location of the Git repository.

Track your project history — this is the first and most obvious reason to use version control, but there are others.

3.2 Manage multiple versions of a project

The second benefit

A second benefit of version control is that you can use it to juggle multiple versions of a project at the same time.

Concrete example: The Marathon Trout application

Imagine you are developing a smartphone app called Marathon Trout — a running tracker for fish. You put this project under version control and commit new features (each circle represents a commit). Maybe every few days you release this app for free to an app store.

Then you decide to have a second paid version with premium features. Now you have two development flows: – A free version

• A premium version

They share most of their code and usually change together, except sometimes. For example:

• Commits common to both versions (bug fixes, common features)
• Premium feature commits only in premium version

The problem without version control

Without version control, this is a complicated situation. You could maintain two completely separate projects and copy and paste the code from one to the other — but that’s a lot of copying and pasting. It would be easy to make mistakes, almost guaranteed, in fact.

The solution: Branching

Version control systems have a solution for this. It’s called branching.

Let’s go back to when you decided to have a premium version. At this point you have a development flow. In Git, this main flow is usually called the main branch (or master in older projects). It can have any name, but main is one of the most common.

Create a new branch:

git branch premium

By creating a second premium branch and working on both branches in parallel, after a while you get a situation with two separate streams.

Navigate between branches:

# Aller vers la branche premium
git switch premium

# Revenir vers la branche main (version gratuite)
git switch main

Note on older versions of Git: On very old versions of Git, git switch may not be available. In this case, we can use git checkout <branch_name>.

Merging

Branching alone does not resolve the problem. How to share code between branches? For example, if commits in the free version are bug fixes that also need to go into the premium version, we use merging:

# Se déplacer vers la branche premium
git switch premium

# Fusionner les changements de main dans premium
git merge main

After this merge, the history of the premium branch includes everything:

• All premium commits (green in diagram)
• And also common commits (in orange)

While the history of the main (free version) branch includes commits from the free version, but not premium commits.

Merge conflicts

Even with a very quick introduction to branching and merging, we already realize one important thing: branching is easy, but merging can be difficult.

For example, what happens when we merge two branches and find that two commits in two branches changed the exact same line of code, but in different ways? We then have a conflict — two conflicting changes that must be reconciled in one way or another. Git can’t do this alone. Only you can do this, because you understand what these changes mean.

In practice, merge conflicts occur frequently. But even then, it’s much easier to resolve these conflicts in a version control system than to simply compare two directories. This is actually one of the reasons to use version control — to make this type of conflict a little more manageable.

Branching beyond versions

This was just one example of why you might want to maintain multiple versions of the same project. In practice, there are many other situations that call for branching. In fact, branching and merging aren’t just useful for maintaining multiple versions of a project — they enable what is probably the main reason to use version control.

3.3 Share code between developers

The challenge of teamwork

Writing software is hard, and writing software as a team is even harder. Sometimes it seems miraculous that people can work together on the same code. The code is meticulous — one small mistake and you get a bug. And it’s all too easy to make these mistakes even when you have full control of your own code.

How ​​can multiple people work together on the same code without constantly trampling on each other’s toes?

Before generalized version control

Before version control was widespread, teams tried very hard not to work on the same code. They did this in a few ways that usually involved dividing the project into several parts, separate modules.

Example: A team writing inventory management software could divide the project into:

• Database access code
• The user interface code
• The administrative interface code
• etc.

We tended to have one developer per piece of the project, and they worked virtually in isolation until it was finally time to put all the pieces together.

The integration phase: This was the famous integration phase, and it was usually a disaster. It was not uncommon to see a large project stuck in the integration phase for many months, while teams desperately tried to make each part work with each other’s parts.

With version control

Almost every team uses version control these days. This makes working on the same code much easier, mainly because version control gives you the repository — a shared, authoritative version of the project that you can use at any time to get the latest changes and integrate your own changes.

Once developers share the repo, they don’t have to wait for a big final integration — they can integrate much more frequently.

Workflow example with branches

Different teams integrate their code in different ways, but most teams use some form of branching and merging convention. For example, a common technique is to create a temporary branch for each new feature or bug fix.

Let’s imagine two developers, Michelle and Aaron:

1. Michelle writes code for a new feature → creates a new branch from main → starts committing code to this branch.
2. Aaron fixes a bug → also creates a branch → commits code to this branch.
3. Aaron finishes quickly → merges his changes into the main branch.
4. Michelle ends her functionality → also merges into main.

The potentially conflicting moment: When Michelle commits her own changes, if she and Aaron have changed the same area of ​​code, she might have to resolve conflicts at this point — putting her code and Aaron’s code together. It’s like going through a mini-integration phase during the merger.

Why integrating frequently is beneficial

One might think: if onboarding is so hard, what’s the point of doing it so often? But it turns out that if you onboard more often, yes, you might still have conflicts, but those conflicts are likely to be small and easy to fix.

Martin Fowler put it well when he said: “If it hurts, do it more often”. Integrating is often painful, even with version control, but as a general rule, the more frequently you do it, the less painful it is — and version control lets you do it very frequently.

Some teams integrate their code several times a day, or even several times an hour.

This is perhaps the most important benefit of version control — it makes code integration much easier. This ultimately means that teamwork in modern software is possible. In the modern world, one generally does not have the luxury of waiting for a long integration phase to complete. Many projects deliver new versions all the time, and this type of frequent delivery is made possible by version control.

3.4 Coordinate teamwork

Beyond Developers

Once you have a repository, all developers can use it as a source of truth to get the current state of the project. But it’s not just limited to developers — it extends to the entire team: managers, testers, sysadmins, and even all the tools the team needs to keep the project under control.

The bug tracker

Most development teams use a bug tracker to manage a list of bugs or changes to be made. Nowadays, bug trackers integrate directly with the source code in the repository:

• A tester who finds a bug can link the bug to the commit where it occurred.
• The developer who fixes the bug can link the bug to the commit where he fixed it.

The same integration happens with tools that help manage the backlog of work to be done, or that allow a team leader to allocate work to team members — like Jira, for example. You can link a task from these tools to the repository, which makes it so much easier to understand what’s going on in a project.

The build machine (automation server)

An essential tool in many projects today is the build machine, sometimes also called an automation server. For example, Jenkins is very popular for this.

The build machine also connects to the repository and typically springs into action whenever the repository changes, doing many useful things:

1. Project construction: Compiles the code if it is written in a compiled language.
2. Packaging: Prepares the code for distribution.
3. Deployment: Perhaps deploys the system to a test machine.
4. Code health monitoring: Runs metrics and especially automated tests.
5. Alert: Raises a flag if your last commit breaks something in the system.

This is extremely useful. Some teams go even further and use their build machine to trigger what is called continuous deployment. This means that the build machine doesn’t just check the code or run the tests — it literally deploys the system into production. Every time we change anything in the source code, this change arrives in production automatically.

Only a small percentage of teams are able to pull off this feat, but some do. This requires a lot of automated testing, of course. But it’s an example of the power of this build machine concept.

All of this can only happen through version control. The repository isn’t just the center of human communication on a team — it’s the center of all development these days. It is crucial for coordinating teamwork.

3.5 Version Control Summary

This module explained why version control is so essential to modern software development:

1. History tracking and time travel

• No need to maintain copies of a project by hand.
• Removing obsolete code with confidence.
• Ability to unravel what happened in your project and when.

2. Multiple version management

• Branching and merging allow you to manage multiple development flows.
• Example: free version and premium version of an application.

3. Code sharing and teamwork coordination

• The repository becomes the center of the project.
• Not only for developers, but for all the people and tools that revolve around the project.
• Developers, testers, managers, bug trackers, and the precious build machine.

Version control is important. But Git is not the only version control system on the market. So why do so many teams use Git specifically? What makes it special? This is the subject of the next module.

4. Understand what makes Git special

Module duration: 18m 15s

4.1 Good reasons to use Git

What makes Git special? Why do so many teams use it? This module walks through some benefits of Git, as well as some limitations.

In particular, we’ll talk about distributed version control — it’s Git’s flagship feature.

The strengths of Git

1. Git is fast

One of the first things you’ll notice when using Git is how fast it is. Most Git operations are so fast that they seem instantaneous: branching, checking out a commit, etc. We cannot say that Git is the fastest version control system, but it is certainly very fast.

2. Git is smart

Git is quite smart in many practical cases that are traditionally difficult in version control. For example :

• If you rename a file or move it to another directory, many version control systems could be disrupted. Not Git. It just continues to follow the file’s history without batting an eyelid.

3. Git is flexible and powerful

This is something developers love. You almost never have to worry about whether you can do something. You can do almost anything with your Git repository. It belongs to you.

If you follow the advanced Git courses, you’ll find that you can do some pretty crazy things, like refactor a project’s history to clean it up. Git is a powerful tool.

4. Git is safe

If your data is in a Git repo and that repo is backed up, of course, then that data is safe:

• Against accidental corruption
• Against intentional corruption (for example, a hacker who wants to slip malicious code into your repository)

Git is both safe and secure. He’s rock solid in that regard.

The flagship feature: Distributed version control

These benefits still don’t explain why so many organizations, even large, traditionally conservative companies, are migrating to Git. The main reason is that migrating to Git means migrating to a different way of doing version control: from client-server version control to distributed version control.

4.2 Client-server version control

Before Git came on the scene, most people used something called client-server version control. One of the most popular client-server version control systems is called Subversion (often called SVN).

The Subversion workflow: Sonia’s example

Let’s meet Sonia. She is a developer and has just joined a team that uses Subversion.

Step 1 — Connect to the repository

The first thing Sonia does after joining the project is to connect to the project’s Subversion repository. In client-server version control, the repository is on a server somewhere in the building or perhaps in the cloud, and everyone on the team connects to it — along with the build machine and other entities that need access to the project. There’s one repository server to rule them all.

  Serveur central
  ┌──────────────┐
  │  Repository  │
  └──────┬───────┘
         │
    ┌────┴────┐
    │         │
  Sonia     Frank
  (client)  (client)

Step 2 — Copying files

Sonia connects to this repository and copies all the project files to her computer, in her local work area — this is called her local working copy of the project files.

Step 3 — Work and Edit

Sonia starts working on these files. Let’s say she needs to fix a bug and edits a file to fix it.

The Problem — A Conflict

Now Sonia wants to commit this file — send it to the server. But not so fast! This is the downside of teamwork. It is possible that while Sonia fixed the bug, one of her colleagues modified this same file in the repo. For example, Frank modified this same file for another reason, perhaps to add new functionality.

The file in the repo is therefore no longer the same as the one that Sonia modified. She can’t just send her file to the server — otherwise she would overwrite Frank’s changes.

The conflict resolution procedure — 3 steps:

1. Récupérer les derniers changements du serveur
   (obtenir les modifications de Frank)
   
2. Résoudre le conflit
   (fusionner les changements de Sonia avec ceux de Frank
   pour obtenir un fichier qui a les deux)
   
3. Envoyer le tout au serveur
   (créer le commit)

This is the basic client-server version control workflow. There may be complications, variations, branches, etc., but that’s the fundamental loop.

This is why we call it client-server: there is a server which contains the repository, and many clients (the developers’ workstations, the build machine, etc.).

4.3 Distributed version control

Distributed version control is not a Git-exclusive feature. There are other distributed version control systems, but Git is by far the most popular, and also the one that made this way of working common. So most people identify distributed version control with Git.

Sonia’s example with Git

Sonia just joined another project at the same company — and that project uses Git. What is she doing differently this time?

The first major difference: the clone

The first difference between working with Subversion and working with Git comes immediately when Sonia connects to the project repository. It doesn’t just connect to the repository — it does something called clone.

git clone <url_du_repository>

What this means is that Sonia copies the entire repository to her machine — everything, project history and everything, including of course the latest commits, i.e. the current project files.

The hidden .git repository

If you want to see a Git project’s repository, you usually don’t have to look very far. In a Git project, if we give the command that displays the contents of a directory, including hidden files and directories:

ls -la
# ou sur Windows :
dir /ah

We see that there is a hidden directory called .git. And this directory contains the Git repository, including the complete project history.

Most often, a project’s Git repository is right there, inside the project directory.

mon-projet/
├── .git/              ← Le repository Git (caché)
│   ├── commits
│   ├── branches
│   └── ...
├── src/
├── README.md
└── package.json

What Sonia can do with her own repo

Now that Sonia has her own repo, she can do whatever she wants with it:

• Create commits
• Create branches
• Checkout of previous versions of the project
• Anything

Synchronization with the rest of the team: pull and push

At some point, Sonia will probably want to sync her changes with the changes of the rest of her team. How does this work in a distributed Git project?

Even though she has her own repo, Sonia maintains a link to the shared repo. In Git terminology, this is called a remote.

# Obtenir les derniers commits du remote vers le repo local
git pull

# Envoyer les commits locaux vers le remote
git push

Just like in client-server version control, Sonia might have to resolve conflicts during these operations. In this case, she:

1. Will do a pull first to get all shared changes
2. Will merge these changes with its local changes
3. Finally, will push its local changes to the team’s shared repo

A peer-to-peer system

To be clear: even if the team has a shared repo, that doesn’t mean Sonia’s repo is a second class citizen. A Git environment is a peer-to-peer system, where there are usually multiple repositories that are all technically of equal value.

By convention, most teams agree that there is a copy of this repo on a shared server, and it is the one that is important and visible to the whole team. Sonia’s repo is less important and may not be shared with other developers. But technically, they’re just multiple copies of the same project history.

In theory, we might not even have a shared server — just a network of repositories of developers who are each others’ remotes, with no server officially the center of the repo. This could be done, although it is rarely practiced.

The benefits of distributed version control

Benefit 1 — Work offline

If Sonia has her own repo, she can still work with version control, even disconnected from the central server. She can’t share code with the rest of the team, but she can still:

• Create commits
• Checkout of branches
• Move through history
• And more

This is a nice feature that works well with remote work, and also removes the single point of failure that is the central repository.

Benefit 2 (and most important) — Workflow flexibility

The biggest benefit of distributed version control goes well beyond this idea of ​​working disconnected from the server. It’s a benefit that’s both more subtle and more powerful.

This is the flexibility to work in different ways than the traditional client-server development workflow — sometimes a little differently, sometimes radically differently.

In the last module of this training, you will see a real-world example: the workflow used by most open source projects today, which would simply be impossible with client-server version control.

4.4 Reasons to be careful with Git

After all these reasons to love Git, here are the real limitations — some are myths, others are legitimate concerns.

The Myths (Invalid Reasons to Avoid Git)

Myth 1 — Lack of access control

Some companies are hesitant to adopt distributed version control because they believe that access cannot be controlled in a distributed system:

• Once repos are distributed, each developer can modify any file.
• We cannot say: “This file is important, only the team leader can modify it.”
• You cannot lock files (feature of some VCS to prevent merge conflicts when owning files).

The Rebuttal: This is not a valid concern. Yes, distributed version control is different — it has other ways of managing access. These different ways are generally more effective than the traditional access control model.

For example, with Git, you can give a team leader the power to accept or reject any changes — just like open source projects do (we’ll see more details in the next module).

And yes, you can’t lock a file and say “no one changes this file except me”, but that’s a good thing — because locking files often hinders work. In practice, it is almost always better to resolve conflicts when they arise rather than trying to prevent them by locking files.

Myth 2 — Copying history on each machine

The idea of ​​having a copy of the project history on each developer’s computer scares some people: “We have a huge project with a long history; it would be madness to copy this history to every workstation.”

The Rebuttal: In most cases this does not turn out to be a problem in practice. Git offers a few ways to handle this:

• Split the project into several smaller repositories.
• Shallow clone — A feature that allows distributing only part of a project’s history, such as the latest commits:

git clone --depth=1 <url>  # Clone seulement le dernier commit

In practice, this is really rarely a problem. The Linux kernel uses Git. The Microsoft Windows project uses a modified version of Git — over 3 million files, thousands of developers. If Git is good enough for them, it probably is good enough for most large projects.

The real limitations of Git

Limitation 1 — Large binary files

Git is great at handling text files like source code, but pretty bad at handling large binary files (videos, big data files, etc.).

If your project contains a lot of them, you might want:

• Keep them out of the repo
• Use something other than Git for these files

Otherwise, they could slow down your repo and take up a lot of disk space.

Note: It’s not just Git — most version control systems aren’t very good with large binary files. But Git is perhaps worse than most. There are a few version control systems that specialize in binary files, and some are even built on top of Git (like Git LFS — Git Large File Storage). But one should not use vanilla Git to store many large binary files.

Limitation 2 — The learning curve

This is the most important reason to be careful with Git — and it’s not a technical reason, it’s a human reason. Git is quite difficult to understand.

First, distributed version control is more difficult to understand than client-server version control in nature. And what’s more, Git wasn’t exactly designed to be user-friendly. It reflects the personality of its creator, Linus Torvalds — the same guy who created the Linux operating system.

Torvalds is a contrarian — he likes to do things his way. He even went so far as to use the same words that other version control systems used, but with a different meaning. For example, the words commit and checkout mean different things in Git than in Subversion, and this can be really confusing when moving from Subversion to Git.

In general, Git takes some getting used to. You won’t master it in an afternoon, and it won’t give you warmth and comfort while learning.

But… once you get past this initial hurdle, Git is worth it. As the trainer says:

“I found Git difficult to learn, but now that I have learned it, I find it easy to use.”

Git is one of those tools that seems really complicated, but once you understand how it works, everything clicks — and it suddenly feels clean and coherent, and has this great feeling of power and control.

4.5 Git Pros and Cons Summary

Advantages of Git:

• Fast — Most operations are almost instantaneous.
• Intelligent — Handles common operations like file renaming well.
• Flexible and powerful — You can do almost anything.
• Safe — Keeps your data safe from accidental and intentional corruption.
• Distributed version control — The flagship feature.

Cons Discussion:

• Myths (no real limitations):
• Lack of access control → resolved differently with Git.
• Copying history → rarely a real problem in practice.
• Real limitations:
• Not very good with large binary files.
• Large learning curve.

5. The Git ecosystem

Module duration: 13m 46s

5.1 Integrate Git into your environment

There is a whole ecosystem of technologies revolving around Git: other tools that communicate with Git, graphical interfaces, online services, etc.

The correct message is: if you need to integrate Git into your current toolset, you probably won’t have many problems. Git is one of those happy situations where one of the best technologies is also one of the most popular — so it has all the support you could need.

Development environments (IDE)

Git GUIs (standalone)

If you want to use Git on its own, but aren’t excited about the command line, there are many standalone GUIs for Git:

• SourceTree (by Atlassian)
• GitKraken
• GitHub Desktop
• Tower
• And many more…

Team Oriented Tools

Git integrates well with all team-oriented tools:

Git is a welcome citizen in virtually any environment these days.

Git-based services

And then there are Git-based services like:

• GitHub
• GitLab
• Bitbucket

This is where the discussion gets deeper, as these services are a great example of the power of distributed version control.

5.2 A GitHub Overview

There are a few online services based on Git. They tend to work similarly, so GitHub is used as an example for all. What is true for GitHub is also true for other services like GitLab and Bitbucket.

Why GitHub is popular

GitHub is a popular tool today because it is useful in several ways:

1. Hosting of repositories

• Create a Git repository in the cloud in just a few clicks.
• Public repositories are free.
• Private repositories (for commercial code that should not be visible to everyone): depending on the service, some offer them for free with limitations, others require a subscription.

# Cloner un repository GitHub sur votre ordinateur local
git clone https://github.com/utilisateur/projet.git

2. Project management

GitHub provides project management tools, such as issue tracking:

• Issues tab on each project.
• Anyone (project members or project users) can open an issue.
• People can discuss these issues.
• GitHub provides the means to connect this discussion to the project history (reference a specific commit, for example).
• Integration with external services (build machines, code metrics systems, etc.).

3. A social network focused on code

GitHub’s communication features are so powerful that it can almost be described as a social network — but focused on code rather than people.

On the GitHub homepage, we see:

• His friends and colleagues
• Their activities
• Contributions to projects
• Ongoing discussions

GitHub is therefore both:

• A repository hosting service
• A set of project management tools
• A kind of social network focused on projects and code

But the most important reason people use GitHub is that it builds on Git to provide a specific workflow for collaborating on software projects — this workflow is even more important for many projects than hosting, issue tracking, and integrations.

5.3 The open source workflow

Presentation

This workflow is very popular nowadays. We can call it the open source workflow — although it’s not just for open source, as we’ll see later.

Reminder: You are not expected to memorize this information. Technical details will not be covered in this training. The goal is to give you a concrete example of a way of working that is only possible with distributed version control. You will probably have many opportunities to learn this way by practicing it.

The initial situation

Let’s meet Sonia, our developer friend. She’s passionate, so she wants to contribute to open source projects on the weekends. She found a project on GitHub that could benefit from some bug fixes.

The GitHub convention is that our repo is identified by <user_name_or_organization>/<project_name>. In Sonia’s case, her GitHub account is called nusco.

Step 1: The Fork

The first thing Sonia needs is her own copy of this repository to work on. Instead of simply cloning the repo on her local machine, Sonia asks GitHub to make a remote clone inside GitHub for her — this is called a fork.

Avant le fork :
  pluralsight/marathonfish (original)

Après le fork :
  pluralsight/marathonfish (original)
  nusco/marathonfish (fork de Sonia)

On GitHub, each project has a button to fork it.

Why a fork rather than a direct local clone?

• The fork is a copy in GitHub — publicly accessible.
• It can be read by everyone, but only written by Sonia.

Step 2: The Local Clone

Sonia then clones her fork (nusco/marathonfish) on her local computer to work on it, and keeps nusco/marathonfish on GitHub as her remote.

git clone https://github.com/nusco/marathonfish.git

  pluralsight/marathonfish (original)
         ↑ pull request
  nusco/marathonfish (fork sur GitHub) ← git push
         ↑ remote
  Machine locale de Sonia

Step 3: Work on the code

Sonia is working on her contributions to the project. It fixes a bug and creates one or more commits in its local repo.

# Créer une branche pour la correction
git branch correction-bug

# Se déplacer sur la branche
git switch correction-bug

# Faire les modifications, puis...
git add .
git commit -m "Correction du bug #42"

Step 4: The Access Problem

Sonia would like to push her commit to the original project, but she does not have permission to push to pluralsight/marathonfish. It belongs to another user.

Open source projects are public, but that certainly doesn’t mean that anyone can just push code to any project. Open source projects have a maintainer — a user or organization who decides what contributions go into the project. In this case, the maintainer is Pluralsight.

Step 5: Push to fork

This is where we see why Sonia created a fork. The fork nusco/marathonfish is readable by everyone. Sonia can therefore push her changes towards her fork:

git push origin correction-bug

Step 6: The Pull Request

Sonia uses GitHub’s defining feature: the pull request. It sends a message to the Pluralsight user that says: “Look, I have a contribution here on this fork of your project, so why don’t you come and get it?”

1. Review changes
2. Revise them if necessary with Sonia
3. Runs the project’s automated tests on Sonia’s changes
4. And hopefully says: “Okay, I like these changes” and pull these changes from Sonia’s fork to the original project

This entire process can happen inside the GitHub interface. The entire process — from sending the pull request to accepting it — can be done on GitHub.

Open source workflow summary

1. FORK  → Créer sa propre copie du repo sur GitHub
               pluralsight/marathonfish → nusco/marathonfish
               
2. CLONE → Cloner son fork localement
               git clone https://github.com/nusco/marathonfish.git
               
3. COMMIT → Faire ses changements et committer
               git add .
               git commit -m "Description du changement"
               
4. PUSH  → Pousser vers son fork
               git push origin ma-branche
               
5. PULL REQUEST → Demander au mainteneur d'intégrer les changements
               (via l'interface GitHub)
               
6. REVIEW → Le mainteneur révise, discute, teste
               
7. MERGE → Le mainteneur fusionne les changements dans le projet original

Additional Shades

In reality, the workflow is a little more complicated. For example, Sonia might need to keep the original project as a remote secondary in addition to her own fork, so that if the original project changes, she can grab the latest commits and resolve any conflicts before sending a pull request.

# Ajouter le projet original comme remote "upstream"
git remote add upstream https://github.com/pluralsight/marathonfish.git

# Récupérer les derniers changements du projet original
git pull upstream main

# Résoudre les conflits si nécessaire, puis pousser vers son fork
git push origin correction-bug

Why this workflow is powerful

If you think about it, this workflow can only exist in a distributed version control system. You cannot have pull requests in a client-server system.

Access control in Git: In the previous module it was mentioned that distributed version control has its own ways of controlling access. Here is one: the fork + pull request workflow. And it works very well.

Some open source projects have thousands of contributors from all over the world — from stable contributors at the core of the project to occasional contributors who might submit a single patch and then disappear. And even with all these people circling around the project, maintainers maintain tight control over what code goes into the project — perhaps even more controlled than the typical internal company project.

Beyond open source

In fact, many companies these days are adopting this pull request-based way of working for their internal projects. So, even though it has been called “the open source workflow”, it is becoming more and more common for closed source (proprietary) projects as well.

5.4 Conclusion of the training

Here we are at the end of this Git: The Big Picture training. It was short, but here’s everything that was covered:

Full Summary

Module 2 — Getting to know Git:

• Demonstrating the basic ideas of version control with Git.
• The idea of ​​creating snapshots of a project — commits.
• The idea of ​​moving forward and backward in the project history.

Module 3 — Understanding version control:

• Overview of version control and reasons to use it.
• Specifically how, for a development team, a version control repository becomes the hub that people use to coordinate teamwork.

Module 4 — Understanding Git:

• What makes Git different from other version control systems.
• The strengths and weaknesses of Git.
• Distributed version control compared to traditional client-server version control.

Module 5 — The Git ecosystem:

• Git integration with other tools.
• Git-based online services, such as GitHub.
• The open source workflow — an example of what is so powerful about distributed version control.

To go further

If you came here to become proficient in Git, this training was the first step. There are other Git training courses on Pluralsight from several authors. In particular, the “How Git Works” course (by the same author) is highly recommended — it focuses on how Git works internally, and once you understand it, everything fits together, and Git feels clean, coherent, and has that great feeling of power and control.

6. Git Commands Quick Reference

Basic commands

Creating commits (snapshots)

History navigation

Branches and merge

Synchronization with remotes

Typical workflow

# 1. Initialiser ou cloner
git init
# ou
git clone https://github.com/utilisateur/projet.git

# 2. Vérifier l'état
git status

# 3. Ajouter les fichiers modifiés
git add .

# 4. Créer un commit
git commit -m "Description de ce qui a changé"

# 5. Voir l'historique
git log

# 6. Créer une branche pour une nouvelle fonctionnalité
git branch ma-fonctionnalite
git switch ma-fonctionnalite

# 7. Travailler, puis fusionner
git switch main
git merge ma-fonctionnalite

# 8. Synchroniser avec le serveur
git pull
git push

7. Glossary of Git terms

Search Terms

git · ci/cd · devops · version · control · workflow · beyond · commits · distributed · history · open · reasons · sonia · source · benefit · between · branches · branching · commands · developers · fork · github · merge · pull