infra / git-github

Initialisation et statut d'un dépôt

Leçon 11 exercice

Explication

Un peu d'histoire

Git est créé par Linus Torvalds (déjà créateur de Linux) en avril 2005, en seulement quelques semaines. La raison est presque accidentelle : la communauté du noyau Linux perd brutalement l'accès gratuit à l'outil propriétaire qu'elle utilisait jusque-là (BitKeeper) et doit trouver une alternative libre, rapidement. GitHub, la plateforme qui héberge des dépôts Git et ajoute des outils de collaboration autour, est lancée en 2008 par Tom Preston-Werner, Chris Wanstrath et PJ Hyett.

Pourquoi apprendre Git et GitHub aujourd'hui

Git est l'outil de gestion de versions utilisé par la quasi-totalité de l'industrie du logiciel, quel que soit le langage. GitHub (avec des alternatives comme GitLab ou Bitbucket) est devenu le cœur du travail d'équipe moderne : revue de code, discussions, intégration continue, gestion de projet. Savoir utiliser Git n'est plus une option pour un développeur, c'est une compétence de base non négociable, au même titre que savoir écrire du code.

Ce que vous allez apprendre

Configurer ton identité Git une bonne fois pour toutes sur une nouvelle machine
Comprendre les trois zones de Git : working directory, staging area, repository
Créer un dépôt local avec git init ou en récupérer un existant avec git clone
Lire un git status et comprendre ce que chaque état de fichier signifie
Prendre le réflexe de vérifier l'état du dépôt avant toute action Git

Dans quel contexte ?

Une développeuse rejoint une entreprise et reçoit un nouvel ordinateur portable. Avant même d'écrire une ligne de code sur le dépôt boutique-api, elle doit configurer son nom et son email Git, cloner le dépôt depuis GitHub, puis vérifier avec git status que son environnement de travail est propre avant de commencer sa première tâche. Cette leçon couvre exactement ces gestes fondateurs.

Le problème avant Git

D'abord, avant Git, beaucoup de gens géraient les versions de leur code en dupliquant des dossiers : "projet_final", "projet_final_v2", "projet_final_vraiment_final".

Pourquoi ce système ne tient pas la route

Ce système s'effondre dès qu'on travaille à plusieurs, ou même seul sur un projet qui évolue dans le temps : comment revenir en arrière précisément, comment savoir ce qui a changé et pourquoi ?

La solution : un historique complet et fiable

Un système de contrôle de version comme Git répond à ce besoin : il garde un historique complet de chaque changement, avec un horodatage, un auteur et une explication, sans jamais dupliquer manuellement de dossiers.

La toute première chose à faire sur une machine

Une fois Git installé, la première action est de configurer son identité, avec git config --global user.name et user.email. Cette information voyage avec chaque commit pour toujours, comme une signature.

Pourquoi cette identité compte vraiment

Ce n'est pas une formalité : dans un travail en équipe, c'est ce qui permet de savoir précisément qui a fait quoi, sur quel fichier, à quel moment.

Le concept le plus important du cours : les trois zones

Git distingue trois "étapes" pour un fichier modifié. D'abord, il existe sur ton disque : c'est le working directory.

La deuxième étape : préparer ce qu'on veut garder

Ensuite, tu choisis ce qui doit être inclus dans le prochain enregistrement, via git add : c'est la staging area.

La troisième étape : rendre le changement définitif

Enfin, cet enregistrement devient définitif dans l'historique via git commit : c'est le repository. Cette séparation en deux étapes permet un contrôle précis : tu peux choisir de n'enregistrer qu'une partie de ton travail.

Zone	Rôle	Commande pour y entrer
Working directory	Fichiers tels qu'ils sont sur ton disque	(modification directe)
Staging area (index)	Ce qui sera inclus dans le prochain commit	`git add`
Repository (`.git`)	Historique définitif des commits	`git commit`

Prérequis

Aucune connaissance préalable de Git n'est nécessaire pour cette leçon. Un simple terminal et Git installé suffisent (git --version pour vérifier).

Le réflexe à prendre dès maintenant

git status est la commande la plus tapée par tout développeur Git au quotidien. Elle répond en permanence à la question "où en suis-je ?" : quels fichiers ont changé, lesquels sont prêts, lesquels ne sont pas encore suivis.

Bonne pratique

Lance systématiquement git status avant un git add, un git commit ou un git checkout. Cette habitude simple évite la grande majorité des erreurs de débutant, comme committer un fichier oublié ou écraser une modification en cours sans le vouloir.

Prends le réflexe de la lancer avant toute action : cela évite la plupart des erreurs de débutant. La prochaine leçon s'appuie directement sur ces trois zones pour créer de vrais commits et explorer l'historique du projet.

Commandes & code

Init & status

# Configuration globale (une seule fois par machine)
git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"

# Voir toute la configuration active
git config --list
git config --list --show-origin     # d'où vient chaque valeur (global, local, système)

# Créer un nouveau dépôt
mkdir mon-projet && cd mon-projet
git init

# Cloner un dépôt existant
git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git      # via SSH (voir leçon push GitHub)

# L'état du dépôt : LA commande la plus utilisée au quotidien
git status

# Version compacte, une ligne par fichier
git status -s
# ?? = fichier non suivi (untracked)
# A  = ajouté à l'index (staged)
#  M = modifié, pas encore ajouté
# M  = modifié ET ajouté

# Les 3 zones de Git
# 1. Working directory : fichiers tels qu'ils sont sur le disque
# 2. Staging area (index) : ce qui sera inclus dans le PROCHAIN commit
# 3. Repository (.git) : historique des commits déjà enregistrés

echo "console.log('hello')" > app.js
git status          # app.js apparaît en "untracked"
git add app.js
git status          # app.js apparaît en "staged" / "to be committed"

Résumé

git config --global configure identité et préférences une seule fois par machine.
git status (ou git status -s) est la commande à taper avant TOUTE action.
Trois zones : working directory -> staging area (git add) -> repository (git commit).

Exercices pratiques

1 disponible

Mission : auditer un dépôt hérité avant le premier commit

Objectif : Interpréter précisément l'état d'un dépôt existant via git status et configurer une identité Git cohérente avant d'ajouter le moindre commit.

Contexte

Tu reprends le dépôt boutique-api laissé par un stagiaire parti sans documentation. Avant de committer quoi que ce soit, tu dois comprendre exactement ce que git status -s te montre et vérifier que ton identité Git est correctement configurée pour ce dépôt précis, pas seulement au niveau global de ta machine.

Résoudre l’exercice →