Git — Les bases

Introduction

Git est un système de contrôle de version. En termes simples, il garde un historique complet de chaque modification que tu fais dans ton code. Chaque fois que tu "sauvegardes" (on dit commit), git prend une photo de l'état de tous tes fichiers à cet instant. Tu peux revenir à n'importe quelle photo à tout moment.

Pourquoi c'est indispensable :

• Sécurité : ton code est sauvegardé sur un serveur distant. Si ton disque dur crame, si tu fais un rm -rf de travers, ton code est en sécurité.
• Historique : tu peux voir exactement ce que tu as modifié, quand, et pourquoi. Si une modification casse quelque chose, tu reviens en arrière.
• Collaboration : plusieurs personnes peuvent travailler sur le même projet en parallèle. Git gère la fusion des modifications.
• Traçabilité : à 42, la Moulinette vérifie que ton code est bien pushé sur le Vogsphere. Pas de push, pas de correction. Git est obligatoire.

Git a été créé en 2005 par Linus Torvalds (le créateur de Linux) parce qu'il avait besoin d'un outil rapide et fiable pour gérer le code du noyau Linux, qui a des millions de lignes et des milliers de contributeurs.

Git est distribué

La plupart des gens imaginent un système centralisé : un serveur unique qui stocke le code, et tout le monde s'y connecte. Git ne fonctionne pas comme ça.

Avec git, chaque personne a une copie complète du projet, incluant tout l'historique. Tu peux travailler, commiter, créer des branches, revenir en arrière — tout ça sans connexion internet, en local sur ta machine.

Le serveur distant (GitHub, GitLab, Vogsphere de 42) n'est qu'un point de synchronisation. Tu y envoies tes modifications quand tu es prêt, et tu récupères celles des autres. Mais le serveur n'est pas indispensable pour travailler — il est indispensable pour partager.

┌──────────────┐     git push     ┌──────────────┐
│  Ton ordi    │ ───────────────> │   Serveur    │
│  (local)     │                  │   (remote)   │
│              │ <─────────────── │              │
│  copie       │     git pull     │  copie       │
│  complète    │                  │  complète    │
└──────────────┘                  └──────────────┘

Les trois zones de git

Git organise ton travail en trois zones. Comprendre ces trois zones c'est comprendre git :

Working directory  ──git add──>  Staging area  ──git commit──>  Repository
   (tes fichiers)                  (index)                     (historique)
       │                              │                            │
   Tu édites ici             Tu choisis ici              Les commits vivent ici

Ce système en trois étapes peut paraître compliqué au début, mais il te donne un contrôle total. Tu peux modifier 10 fichiers, mais n'en commiter que 3. Tu peux vérifier exactement ce qui va être commité avant de le faire.

Configurer git

Identité

Avant de pouvoir commiter, git a besoin de savoir qui tu es. Chaque commit porte un nom et un email — c'est ce qui apparaît dans l'historique.

Un flag (ou option) c'est un paramètre qui commence par - ou -- et qui modifie le comportement d'une commande. Le flag --global applique la configuration à tout ton système (tous tes projets). Sans --global, la configuration ne s'applique qu'au projet courant.

Pour vérifier :

Éditeur par défaut

Certaines commandes git ouvrent un éditeur de texte (pour écrire un message de commit, par exemple). Par défaut c'est souvent vim. Si tu préfères nano :

Où est stockée la config ?

• --global → ~/.gitconfig
• Sans flag → .git/config dans le projet

Créer un dépôt

Deux façons de démarrer :

git init — Créer un nouveau dépôt

git clone — Copier un dépôt existant

La différence entre clone et simplement copier un dossier : clone établit automatiquement la connexion avec le serveur distant (le "remote"). Tu pourras faire git push et git pull sans configuration supplémentaire.

Le cycle de base : status, add, commit, push

C'est le workflow que tu vas répéter des centaines de fois :

1. Tu modifies tes fichiers
2. git status      → tu vérifies ce qui a changé
3. git add         → tu prépares les fichiers à commiter
4. git commit      → tu crées un snapshot
5. git push        → tu envoies au serveur

git status — Où en suis-je ?

Après avoir modifié un fichier suivi :

Après git add :

Après git commit :

Prends l'habitude de faire git status avant chaque add et avant chaque commit. C'est ton GPS.

git add — Préparer les fichiers

Le . signifie "tout dans le dossier courant et ses sous-dossiers". C'est pratique mais dangereux — tu peux ajouter des fichiers que tu ne voulais pas (fichiers compilés, fichiers temporaires). Toujours faire git status avant pour vérifier.

Le fichier reste modifié, mais n'est plus staged.

git commit — Créer un snapshot

Le flag -m permet d'écrire le message directement. Sans -m, git ouvre un éditeur de texte pour que tu écrives le message.

• Décrit ce que tu as fait, pas ce que tu vas faire
• Est court et précis (une ligne, 50 caractères max idéalement)
• Commence par un verbe d'action : "add", "fix", "update", "remove"

Bons messages :

add ft_putchar function
fix segfault in ft_split with empty string
update Makefile to include bonus rule
remove unused variable in ft_strlen

Mauvais messages :

update            ← trop vague, update quoi ?
fix               ← fix quoi ?
wip               ← personne ne saura ce que tu faisais
asdfgh            ← sérieusement
j'ai fini         ← fini quoi ?

git push — Envoyer au serveur

Après le push, ton code est en sécurité sur le serveur. Les autres (et la Moulinette) peuvent y accéder.

Ça veut dire que le serveur a des commits que tu n'as pas. Il faut d'abord faire git pull pour récupérer les changements, puis repusher.

git pull — Récupérer du serveur

1. Télécharge les nouveaux commits du serveur
2. Fusionne les changements du serveur avec les tiens

Si tu travailles seul, ça se passe automatiquement sans conflit. En équipe, c'est différent — mais les branches et la gestion de conflits sont des sujets plus avancés.

Voir l'historique

git log — L'historique des commits

Chaque commit affiche :

• L'identifiant unique : une longue suite de lettres et chiffres (40 caractères). C'est le numéro de série du commit — aucun autre commit n'aura le même.
• HEAD -> master : indique que c'est le commit le plus récent de la branche master.
• L'auteur et la date.
• Le message.

Un commit par ligne, avec le hash court (7 caractères) et le message.

git diff — Voir les modifications

Les lignes avec + sont ajoutées (en vert dans le terminal). Les lignes avec - sont supprimées (en rouge). Les lignes sans signe sont le contexte.

Ignorer des fichiers — .gitignore

Certains fichiers ne doivent jamais être versionnés :

• Les fichiers compilés (.o, .a, a.out) — ils sont regénérés à chaque compilation
• Les fichiers temporaires de l'éditeur (.swp, ~)
• Les fichiers spécifiques à l'OS (.DS_Store sur macOS)
• Les fichiers contenant des secrets (clés API, mots de passe)

Le fichier .gitignore à la racine du projet liste les patterns à ignorer :

Une fois dans le .gitignore, les fichiers n'apparaissent plus dans git status et ne sont plus ajoutés par git add ..

.gitignore typique à 42

# Compiled files
*.o
*.a
*.so
*.dylib
a.out

# Editor files
*~
*.swp
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

# Debug
*.dSYM/

Mets ce .gitignore dans chaque projet dès le premier commit. C'est une bonne habitude.

La clé SSH

Pourquoi SSH ?

Pour communiquer avec un serveur git (GitHub, Vogsphere), il faut prouver ton identité. Deux options :

• HTTPS : tu donnes ton login + mot de passe à chaque push. Pratique mais pénible.
• SSH : tu configures une paire de clés une fois, et ensuite l'authentification est automatique.

À 42 on utilise SSH.

Comment ça marche

SSH utilise un système de deux clés liées : une clé privée (que tu gardes secrète) et une clé publique (que tu donnes au serveur). C'est comme une boîte aux lettres : tout le monde peut y déposer du courrier (clé publique = la fente), mais seul toi peut l'ouvrir (clé privée = la clé de la boîte). Le serveur vérifie que tu es bien le propriétaire de la clé publique en te posant une question que seul quelqu'un avec la clé privée peut résoudre.

• La clé privée reste sur ta machine, dans ~/.ssh/. Ne la partage jamais. C'est l'équivalent de ton mot de passe.
• La clé publique est donnée au serveur (GitHub, Vogsphere). Elle permet au serveur de vérifier que c'est bien toi.

Générer une clé SSH

• -t ed25519 : ed25519 c'est le type de clé recommandé. C'est le plus récent et le plus sûr. Si ça ne marche pas sur ton système, utilise -t rsa -b 4096 à la place.
• -C : un commentaire pour identifier la clé (convention : ton email).
• Passphrase : un mot de passe qui protège ta clé privée. Tu peux laisser vide pour plus de confort, mais c'est moins sûr.

Deux fichiers sont créés :

• ~/.ssh/id_ed25519 — la clé privée (ne la partage JAMAIS)
• ~/.ssh/id_ed25519.pub — la clé publique (c'est celle-ci que tu donnes)

Ajouter la clé au serveur

Copie tout (de ssh-ed25519 à la fin).

Ce message veut dire que ça marche. Le "does not provide shell access" est normal — GitHub n'est pas un serveur shell, c'est un serveur git.

Permissions de la clé

La clé privée doit avoir les permissions 600 (toi seul peut la lire). Sinon SSH refuse de l'utiliser :

Si tu vois l'erreur "UNPROTECTED PRIVATE KEY FILE", c'est que les permissions sont trop ouvertes.

ssh-agent — Éviter de retaper la passphrase

Si tu as mis une passphrase sur ta clé, SSH te la demande à chaque utilisation. Pour l'éviter :

L'agent SSH retient ta passphrase jusqu'à la fermeture du terminal.

Annuler des erreurs

Annuler les modifications d'un fichier (avant add)

Le fichier revient à son état du dernier commit. Attention : les modifications non commitées sont perdues définitivement.

Annuler un add (unstage)

Le fichier sort de la staging area mais tes modifications sont conservées.

Modifier le dernier commit

Tu as oublié un fichier, ou tu veux corriger le message :

Revenir à un commit précédent (pour voir)

Tu es en mode "détaché" (detached HEAD). Tu peux regarder le code à ce point de l'historique. Pour revenir au présent :

git reset — Revenir en arrière (avec ou sans perte)

Commandes utiles

git show — Voir le contenu d'un commit

Affiche le message et les modifications du commit.

git blame — Qui a écrit cette ligne ?

Pour chaque ligne : quel commit l'a introduite, par qui, et quand. Utile pour comprendre l'historique d'un fichier.

git stash — Mettre de côté temporairement

Tu as des modifications en cours mais tu dois changer de contexte (un hotfix, un autre exercice) :

C'est comme une pile de brouillons.

Bonnes pratiques

Le cycle quotidien

Le workflow git que tu vas répéter tous les jours :

1. Coder / modifier tes fichiers
2. git status pour vérifier ce qui a changé
3. git add pour préparer les fichiers
4. git commit -m "message clair" pour sauvegarder
5. git push pour envoyer au serveur

Commite souvent, en petits incréments logiques. Un commit par fonctionnalité ou par correction. Pas un gros commit avec 10 changements différents.

Avant de rendre un projet

Checklist :

1. git status — tout est commité ? Rien en rouge ?
2. git log — le dernier commit a le bon contenu ?
3. git push — tout est pushé ?
4. Vérifie sur l'interface web que le bon commit est visible
5. Lis le sujet une dernière fois pour vérifier que tu n'as rien oublié

Questionnaire