Bases de Git : branches, fusions et demandes d'extraction

Git suit les instantanés de votre projet au fil du temps. Une branche est un pointeur mobile vers un commit. Fusion combine les historiques (souvent après examen). Une pull request (ou demande de fusion) est la couche sociale : discutez des différences, exécutez CI, puis intégrez. Cette leçon relie le modèle mental aux commandes quotidiennes.

Widgets dans cette leçon : git-graph montre une topologie réelle : utilisez-le pour voir pourquoi des conflits de fusion se produisent lors de la jointure. Pipeline est le chemin des octets de votre éditeur vers la télécommande partagée. Explorateur de code annote les commandes que vous saisirez quotidiennement. Tableau de comparaison explique les compromis entre fusion et rebase. Le code à onglets contient des recettes pour la synchronisation et la récupération.

Visuel : branchement de fonctionnalité et validation de fusion

Avant les commandes, regardez le graphique : main déplacé de c1 → c2, puis feature/login a ajouté c3 au-dessus de c2. La fusion a amené c3 dans main en tant que c4. Si deux personnes éditaient les mêmes lignes depuis c2, Git s'arrêterait lors de la fusion avec un marqueur de conflit : votre travail consisterait à produire le fichier combiné correct.

Chaque point est un commit ; les voies sont des branches. Cliquez sur commits : c4 (fusion) a deux parents : c3 de la fonctionnalité et c2 de la principale. C'est ainsi que Git enregistre la jonction de deux lignes d'historique.
GIT GRAPH · 2 branches · 4 commits
fusionnerprincipalfonctionnalité/connexion
Git graph
Click a commit to see details
principal
fonctionnalité/connexion
4 commits · 2 branches · click a commit to inspect
De l'arbre de travail à la télécommande

Vos fichiers se trouvent dans le répertoire de travail. `git add` place un instantané dans l'index (staging). `git commit` enregistre cet instantané dans le dépôt local. `git push` envoie les commits à une distant (par exemple origin) afin que les coéquipiers puissent les extraire.

Étapes du pipeline : Modifier est un chaos non engagé : vous seul le voyez. Staging est l'aperçu du prochain commit (`git diff --cached`). Commit gèle l'historique localement (hors ligne). Push publie ; jusque-là, les sauvegardes et CI ne voient pas votre travail. PR ajoute une révision + des vérifications automatisées avant que la validation de fusion n'atterrisse sur main.

Cliquez sur chaque étape : cela reflète ce qui se passe sur votre disque et sur le serveur. Si CI échoue après le push, corrigez et modifiez ou ajoutez des validations sur la même branche : les PR sont automatiquement mis à jour.
Modifier
fichiers non validés
git ajouter
mise en scène / index
git commit
DAG local des commits
git pousser
origine (à distance)
RP/revue
Portes CI + fusion
▶
Anatomie des commandes courantes

Explorateur de code : chaque ligne est un moment d'enseignement : cliquez dans l'ordre. Préférez `git switch` pour les changements de branche sur un Git plus récent ; « checkout » apparaît toujours dans les anciens documents.

Lisez les explications à droite de chaque commande : elles correspondent au pipeline ci-dessus (branche → étape → validation → push).
bash
1
git checkout -b feature/login
▼
2
# edit files, then:
▼
3
git status
▼
4
git diff
▼
5
git add -p
▼
6
git commit -m "feat: login form"
▼
7
git push -u origin feature/login
▼
Fusionner ou rebaser (quand vous êtes prêt)

Les deux intègrent votre fonctionnalité avec main. Merge ajoute un commit de fusion (comme c4 dans le graphique). Rebase rejoue vos commits en tant que nouveaux commits au-dessus du main : l'historique semble linéaire mais réécrit les SHA. Ne rebasez jamais les branches publiques sur lesquelles vos coéquipiers ont basé leur travail.

Utilisez ce tableau lorsque vous choisissez une stratégie d'intégration dans des contextes de relations publiques ou localement : la fusion préserve la vérité, le rebase embellit le récit.
FusionnerRebase
Graphique de l'historiqueConserve la bulle de fourche et de fusion : montre honnêtement le travail parallèleSéquence linéaire : les validations de fonctionnalités apparaissent après la dernière version principale - git log plus simple --oneline
CollaborationSûr lorsque plusieurs personnes touchent la même branche : pas de réécriture de l'historiqueDangereux si d’autres personnes ont retiré vos anciens SHA : coordonnez ou évitez
Résolution des conflitsUne résolution de conflit de fusion au moment de la fusionPotentiellement un conflit par commit rejoué – plus granulaire mais fastidieux
Utilisation typiqueGitHub/GitLab par défaut « Créer un commit de fusion »git pull --rebase avant push ; rebase interactif pour écraser les corrections
Liste de contrôle des demandes de tirage

Avant de demander un examen

Les petits PR fusionnent plus rapidement et détectent les bugs plus tôt. CI doit être vert ; incluez ce que vous avez testé manuellement.
Décrivez l'intention dans le titre/le corps du PR, pas seulement dans la différence.
Lien problème/ticket ; mentionner les zones à risque (authentification, paiements, migrations).
Si CI échoue, corrigez ou expliquez : ne comptez pas sur les réviseurs pour déboguer le pipeline.
Mettre à jour la branche de fonctionnalités à partir du principal
bash
git fetch origin
git checkout feature/login
git merge origin/main
# or: git rebase origin/main
Pratique : créez un dépôt de test sur GitHub/GitLab, ouvrez deux clones, simulez deux développeurs et résolvez un conflit de fusion délibéré : rien n'enseigne à Git comme une véritable résolution de conflit.