Collaborer efficacement avec Git et GitHub

🎯 Objectifs

• Collaborer via GitHub (remotes, push, pull)
• Créer et gérer des Pull Requests
• Résoudre les conflits de merge
• Utiliser stash, rebase et tags
• Rebaser sa branche sur main avant une mise en production
• Appliquer un workflow d'équipe

📋 Prérequis

• Module Débuter avec Git complété
• Un compte GitHub

🌐 Remotes et GitHub

Un remote est une copie distante de votre dépôt (hébergée sur GitHub, GitLab…).

Lier un dépôt local à GitHub

git remote add origin git@github.com:user/mon-projet.git
git push -u origin main

💡 -u lie la branche locale à la branche distante. Les push suivants se font avec git push seul.

Cloner un dépôt existant

git clone git@github.com:user/mon-projet.git
cd mon-projet

Récupérer les modifications distantes

git pull origin main

Configurer une clé SSH (recommandé)

ssh-keygen -t ed25519 -C "votre@email.com"
cat ~/.ssh/id_ed25519.pub

Copiez la clé publique et ajoutez-la dans GitHub → Settings → SSH and GPG keys.

🤝 Pull Requests (PR)

Une PR est une demande de fusion d'une branche vers une autre, avec revue de code.

Workflow type

# 1. Créer une branche
git checkout -b feature/auth

# 2. Travailler et committer
git add . && git commit -m "feat: ajouter l'authentification"

# 3. Pousser la branche
git push -u origin feature/auth

# 4. Créer la PR sur GitHub → Review → Merge

Bonnes pratiques PR

⚡ Résoudre les Conflits

Un conflit survient quand deux branches modifient la même ligne du même fichier.

Format d'un conflit

<<<<<<< HEAD
const port = 3000;
=======
const port = 8080;
>>>>>>> feature/config

• HEAD = votre branche actuelle
• feature/config = la branche entrante

Résolution

1. Ouvrir le fichier et choisir la bonne version (ou combiner)
2. Supprimer les marqueurs <<<, ===, >>>
3. Sauvegarder

git add .
git commit -m "fix: résoudre le conflit sur config"

💡 VS Code propose des boutons Accept Current / Incoming / Both pour résoudre visuellement.

📦 Stash

Le stash met de côté vos modifications non committées pour y revenir plus tard.

# Mettre de côté les modifications
git stash

# Lister les stashs
git stash list

# Récupérer le dernier stash
git stash pop

# Supprimer un stash sans l'appliquer
git stash drop

💡 Utile quand vous devez changer de branche en urgence sans committer un travail incomplet.

🔀 Merge vs Rebase

Merge

Préserve l'historique complet et crée un commit de fusion.

git checkout main
git merge feature/auth

main:     A ──── B ──── C ─────────── M
                          \           /
feature:                   D ──── E ─┘

Rebase

Réécrit l'historique pour obtenir une ligne droite.

git checkout feature/auth
git rebase main

main:     A ──── B ──── C
                          \
feature:                   D' ──── E'

Quand utiliser quoi ?

⚠️ Ne jamais rebase une branche déjà poussée et partagée. Cela réécrit les commits et crée des conflits pour les autres développeurs.

🚀 Rebaser sa branche sur main (en pratique)

Pourquoi faire ça ?

Tu travailles sur ta branche feature/paiement depuis deux jours.

Pendant ce temps, tes collègues ont mergé d'autres PR dans main.

Résultat : ta branche est en retard par rapport à main.

Si tu ouvres une PR maintenant, tu risques des conflits, des tests qui passent localement mais pas en CI, et une intégration difficile.

La solution : mettre ta branche à jour avant de pousser.

L'analogie

Imagine que tu travailles sur un document partagé hors ligne.

Quand tu reviens en ligne, tu dois d'abord récupérer les modifications des autres, puis réappliquer les tiennes par-dessus.

C'est exactement ce que fait le rebase.

Le workflow complet

# 1. Se positionner sur sa branche de travail
git checkout feature/paiement

# 2. Récupérer l'état du dépôt distant (sans rien modifier)
git fetch origin

# 3. Rebaser sa branche sur le main distant
git rebase origin/main

# 4. Pousser la branche mise à jour
git push --force-with-lease

Ce que fait chaque commande

git checkout feature/paiement

Tu te déplaces sur ta branche. C'est le point de départ obligatoire : toutes les commandes suivantes s'appliquent à cette branche.

git fetch origin

Tu demandes à Git de télécharger l'état actuel du dépôt distant (GitHub), sans toucher à tes fichiers locaux.

Après ce fetch, Git connaît la position exacte de origin/main - c'est-à-dire le main tel qu'il est sur GitHub en ce moment.

💡 C'est différent de git pull : fetch ne modifie rien, il observe.

git rebase origin/main

Git déplace tes commits au-dessus du dernier commit de origin/main.

Concrètement :

1. Git "retire" temporairement tes commits
2. Il avance ta branche jusqu'au bout de origin/main
3. Il "rejoue" tes commits un par un par-dessus

Avant le rebase :

origin/main:  A ── B ── C ── D
                   \
feature:            E ── F

Après git rebase origin/main :

origin/main:  A ── B ── C ── D
                               \
feature:                        E' ── F'

Tes commits E et F deviennent E' et F' : même contenu, mais une nouvelle base.

⚠️ Si un conflit apparaît pendant le rebase, Git s'arrête. Tu résous le conflit, puis tu continues avec git rebase --continue. Pour tout annuler : git rebase --abort.

git push --force-with-lease

Comme tes commits ont été réécrits (nouveaux identifiants), un git push classique sera refusé.

Tu dois forcer la mise à jour de la branche distante.

--force-with-lease est la version sécurisée du --force :

• --force : écrase aveuglément la branche distante, même si quelqu'un d'autre a poussé entre-temps.
• --force-with-lease : vérifie d'abord que personne d'autre n'a modifié la branche depuis ton dernier fetch. Si quelqu'un a poussé, Git refuse et te prévient.

💡 Règle d'or : utilise toujours --force-with-lease plutôt que --force. Et ne force jamais sur main.

En résumé

git checkout feature/paiement   # je me place sur ma branche
git fetch origin                 # je récupère l'état de GitHub
git rebase origin/main           # je rebase sur le main à jour
git push --force-with-lease      # je pousse la branche réécrite

🏷️ Tags

Les tags marquent des points importants dans l'historique (releases, versions).

# Tag léger
git tag v1.0.0

# Tag annoté (recommandé)
git tag -a v1.0.0 -m "Release 1.0.0"

# Pousser les tags sur le remote
git push --tags

# Lister les tags
git tag -l

🔄 Workflows Courants

Feature Branch (le plus simple)

Chaque fonctionnalité = une branche. On merge dans main via PR.

main     ─────────────────────── M ────
           \                    /
feature     └── A ──── B ──── C┘

GitHub Flow

1. main est toujours déployable
2. Créer une branche pour chaque changement
3. Ouvrir une PR pour revue
4. Merge dans main → déploiement automatique

💡 Idéal pour les équipes qui déploient en continu (CD).

GitFlow

Branches dédiées : main, develop, feature/*, release/*, hotfix/*.

⚠️ Plus complexe - adapté aux projets avec des cycles de release formels (logiciels versionnés, apps mobiles).

🔍 Log Avancé

# Vue graphique de toutes les branches
git log --graph --oneline --all

* a3f7b2c (HEAD -> main) Merge branch 'feature/auth'
|\
| * d1e2f3a feat: ajouter l'authentification
| * b4c5d6e feat: ajouter le formulaire login
|/
* 1a2b3c4 feat: initialiser le projet

📚 Commandes Essentielles

🎯 Points Clés

• Les remotes connectent votre dépôt local à GitHub (ou autre)
• Les PR sont le standard pour la revue de code en équipe
• Les conflits se résolvent en choisissant la bonne version et supprimant les marqueurs
• Merge préserve l'historique, rebase le linéarise - ne rebasez jamais une branche partagée
• Pour mettre à jour sa branche avant une PR : fetch origin → rebase origin/main → push --force-with-lease
• Adoptez un workflow adapté à la taille de votre équipe

📚 Ressources

• GitHub Docs - Pull Requests
• Atlassian - Merge vs Rebase
• Git Flow - Vincent Driessen
• Oh Shit, Git!?!

🚀 Prochaines étapes

Vous collaborez efficacement avec Git. Découvrez maintenant la conteneurisation :

1. Docker expliqué simplement : lancer ses premiers conteneurs - Concepts, images et premières commandes Docker