Les Branches avec Git

Qu’est-ce qu’une branche ?

Dans Git, une branche est simplement un pointeur mobile vers l’un de vos commits. La branche par défaut s’appelle généralement main.

Lorsque vous créez une nouvelle branche, vous dupliquez virtuellement le pointeur actuel pour pouvoir travailler sur une nouvelle fonctionnalité ou un correctif sans perturber le code stable de la branche principale.

---

Pourquoi utiliser des branches ?

• Isolation : Vous pouvez travailler sur une fonctionnalité complexe pendant plusieurs jours sans casser le code de production sur main.
• Parallélisme : Plusieurs développeurs peuvent travailler sur des fonctionnalités différentes en même temps sur des branches distinctes.
• Sécurité : Si votre idée ou votre test ne fonctionne pas, il vous suffit de supprimer la branche sans aucun impact sur le reste du projet.

---

Exercice Pratique : Expérimenter l’isolation des branches

Suivez les instructions dans le simulateur ci-dessous pour créer une branche, y ajouter un fichier, commiter, puis revenir sur main pour observer la disparition temporaire du fichier :

Commandes à exécuter

1

git branch Affiche la liste des branches locales. L'astérisque indique la branche active.

2

git switch -c feature-contact Crée la branche 'feature-contact' et bascule dessus.

3

echo '<h1>Contact</h1>' > contact.html Crée le fichier contact.html uniquement sur cette branche.

4

git add contact.html Ajoute contact.html à la Staging Area.

5

git commit -m "Ajoute contact.html" Enregistre la modification dans l'historique de la branche.

6

git switch main Bascule à nouveau sur la branche principale main.

7

ls Liste les fichiers de main. Notez que contact.html n'est pas présent ici !

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

---

Résumé des commandes de navigation

• Lister les branches locales : git branch
• Créer une branche : git branch <nom-de-branche>
• Basculer sur une branche : git switch <nom-de-branche> (ou git checkout <nom-de-branche>)
• Créer et basculer : git switch -c <nom-de-branche> (ou git checkout -b <nom-de-branche>)

---

Fiches de révision

Entraînez-vous à retenir les concepts clés en cliquant sur les cartes ci-dessous :

Question

Qu'est-ce qu'une branche dans Git ?

Cliquer pour révéler la réponse

Réponse

Une branche est un pointeur mobile vers un commit qui permet d'isoler le développement d'une fonctionnalité sans affecter la branche principale.

Cliquer pour voir la question

Question

Quelle commande permet de basculer d'une branche à une autre ?

Cliquer pour révéler la réponse

Réponse

git switch <nom-de-branche> (ou git checkout <nom-de-branche>)

Cliquer pour voir la question

Question

Quelles sont les conventions de nommage pour une branche de fonctionnalité ?

Cliquer pour révéler la réponse

Réponse

On utilise le préfixe feature/ suivi du nom de la fonctionnalité, par exemple feature/login ou feature/dashboard.

Cliquer pour voir la question

Question

Quel est l'avantage principal d'utiliser des branches de fonctionnalités ?

Cliquer pour révéler la réponse

Réponse

L'isolation : plusieurs développeurs peuvent travailler simultanément sur des fonctionnalités différentes sans interférer avec le code stable de la branche main.

Cliquer pour voir la question

---

Quiz Final — Validez vos connaissances

1. Qu'est-ce qu'une branche dans Git ?

A Une copie physique complète du projet sur le disque dur B Un pointeur mobile vers un commit C Un dossier séparé créé sur GitHub D Un fichier de configuration de Git

2. Quelle commande crée une nouvelle branche ET bascule dessus ?

A git branch nouvelle-branche B git switch -c nouvelle-branche C git merge nouvelle-branche D git push nouvelle-branche

3. Que se passe-t-il si vous créez un fichier sur une branche et revenez sur main ?

A Le fichier est supprimé définitivement B Le fichier reste visible sur main C Le fichier n'est pas visible sur main, mais existe toujours sur la branche D Git affiche une erreur de conflit

---

Prochaine étape

Vos modifications sur la branche feature-contact sont prêtes. Comment les ramener sur notre branche principale main ? C’est ce que nous allons voir avec la fusion (Merge).

Étape suivante : Fusionner des Branches

---

Partie 2 — Comment travaillent les équipes modernes

Le workflow professionnel utilisé par les équipes d’ingénierie modernes suit un processus en 7 étapes :

1. Issue — Une tâche ou fonctionnalité est décrite et assignée dans un outil de suivi (GitHub Issues, Jira, etc.).
   Exemple : « Ajouter une page de connexion »

2. Branch — Une nouvelle branche est créée à partir de main pour isoler le travail.
   Exemple : feature/login

3. Commit — Le développeur réalise des commits réguliers avec des messages clairs et conventionnels.

4. Push — Les commits sont envoyés vers le dépôt distant (GitHub, GitLab, etc.).

5. Pull Request — Une demande de fusion est ouverte pour que l’équipe examine les changements.

6. Review — Les collègues vérifient le code : qualité, sécurité, tests, architecture.

7. Merge — Une fois approuvée, la Pull Request est fusionnée dans main.

Pourquoi ce workflow est-il puissant ?

• Collaboration — plusieurs développeurs peuvent travailler simultanément sans conflits majeurs.
• Qualité — la revue de code réduit les bugs et améliore la maintenabilité.
• Traçabilité — chaque modification est liée à une Issue et une Pull Request.
• Sécurité — main reste stable tant que les changements n’ont pas été validés.

---

Partie 3 — Types de branches

Les équipes utilisent généralement plusieurs catégories de branches pour organiser leur travail.

main

La branche principale du projet. Elle représente la version stable et prête pour la production.

main

Règle d’or : Ne jamais développer directement sur main. Toute modification doit passer par une Pull Request.

feature/*

Branches de développement pour de nouvelles fonctionnalités.

feature/login
feature/dashboard
feature/profile
feature/payment

Quand l’utiliser ? Dès que vous commencez à travailler sur une nouvelle fonctionnalité. La branche est supprimée après fusion.

hotfix/*

Corrections urgentes à appliquer directement sur la version de production.

hotfix/login-bug
hotfix/security-patch

Quand l’utiliser ? Un bug critique est découvert en production et doit être corrigé immédiatement, sans attendre le cycle de release.

release/*

Préparation d’une nouvelle version du projet.

release/v1.0.0
release/v2.0.0

Quand l’utiliser ? Avant de déployer une nouvelle version, pour stabiliser le code, mettre à jour la documentation et les versions.

Exemple complet

main
 │
 ├── feature/login
 ├── feature/dashboard
 ├── hotfix/security
 └── release/v1.0.0

---

Partie 4 — Conventions de commits

Un commit doit expliquer clairement ce qui a changé et pourquoi. Les conventions de messages de commit rendent l’historique lisible et professionnel.

Mauvais exemples

git commit -m "modification"
git commit -m "test"
git commit -m "fix"

Ces messages ne donnent aucune information utile sur le changement effectué.

Bons exemples

git commit -m "feat: add login page"
git commit -m "fix: resolve login redirect loop"

Conventions principales

Préfixe	Usage	Exemple
feat:	Nouvelle fonctionnalité	feat: add dashboard
fix:	Correction de bug	fix: resolve login issue
docs:	Documentation	docs: update README
refactor:	Amélioration du code sans changement fonctionnel	refactor: simplify auth service
security:	Correction de sécurité	security: sanitize user inputs
chore:	Maintenance (dépendances, config)	chore: update dependencies

Pourquoi ces conventions existent-elles ?

• Lisibilité — l’historique des commits devient un journal de bord clair.
• Automatisation — outils de génération de changelog, versioning sémantique.
• Professionnalisme — une base de code bien maintenue reflète une équipe organisée.

---

Partie 5 — Atelier pratique

Mettez en pratique tout ce que vous avez appris avec cette série d’exercices.

Exercice 1 — Créer un projet

Commandes à exécuter

1

mkdir workflow-demo Crée un dossier pour le workshop.

2

cd workflow-demo Se déplace dans le dossier.

3

git init Initialise un nouveau dépôt Git.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Exercice 2 — Premier commit

Commandes à exécuter

1

echo '# Workflow Demo' > README.md Crée le fichier README.md.

2

git add . Ajoute tous les fichiers à la Staging Area.

3

git commit -m "feat: initial project" Crée le premier commit avec un message conventionnel.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Exercice 3 — Créer une branche

Commandes à exécuter

1

git branch feature/login Crée une nouvelle branche nommée 'feature/login'.

2

git branch Liste toutes les branches locales. L'astérisque indique la branche active.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Exercice 4 — Basculer sur une branche

Commandes à exécuter

1

git checkout feature/login Bascule sur la branche 'feature/login' (méthode classique).

2

git switch main Revient sur 'main' avec la commande moderne 'switch'.

3

git switch -c feature/login Crée ET bascule sur la nouvelle branche en une seule commande.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Exercice 5 — Travailler sur une branche

Commandes à exécuter

1

echo '<h1>Connexion</h1>' > login.html Crée un fichier login.html sur la branche 'feature/login'.

2

git add . Ajoute le fichier à la Staging Area.

3

git commit -m "feat: add login page" Commite le fichier avec un message conventionnel.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Exercice 6 — Observer l’isolation

Commandes à exécuter

1

git switch main Bascule sur la branche principale.

2

ls Le fichier login.html n'est pas visible ici. Il est isolé sur 'feature/login'.

3

git branch --list feature/login La branche et son contenu existent toujours.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Pourquoi ? Parce que chaque branche possède son propre espace de travail. Le fichier login.html n’existe que sur feature/login.

Exercice 7 — Fusionner une branche

Commandes à exécuter

1

git merge feature/login Fusionne la branche 'feature/login' dans 'main'.

2

ls Le fichier login.html apparaît maintenant sur 'main' après la fusion.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Exercice 8 — Consulter l’historique

Commandes à exécuter

1

git log --oneline --graph --all Affiche l'historique complet avec le graphe des branches.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Simulation d’équipe

Imaginez trois développeurs travaillant simultanément :

• Développeur A — feature/login
• Développeur B — feature/dashboard
• Développeur C — feature/profile

Chacun crée sa branche, réalise ses commits, puis ouvre une Pull Request. Une fois la review validée, la branche est fusionnée dans main. Le projet progresse sans chaos.

Mini Challenge

Créez la structure suivante :

main
 │
 ├── feature/homepage
 ├── feature/contact
 └── feature/profile

Objectifs :

1. Créer trois branches à partir de main
2. Ajouter un fichier différent sur chaque branche (homepage.html, contact.html, profile.html)
3. Réaliser plusieurs commits sur chaque branche
4. Revenir sur main et fusionner chaque branche
5. Consulter l’historique avec git log --oneline --graph --all

---

Questions de réflexion

1. Pourquoi ne faut-il pas développer directement sur main ?
2. Pourquoi les branches facilitent-elles la collaboration ?
3. Pourquoi les conventions de commits sont-elles importantes ?
4. Que se passerait-il si cinquante développeurs travaillaient directement sur main ?
5. Pourquoi les Pull Requests existent-elles ?

---

À retenir

• Une branche est une ligne de développement indépendante.
• Le workflow moderne : Issue → Branch → Commit → Push → Pull Request → Review → Merge.
• Les branches permettent l’isolation, la sécurité, la collaboration et le développement parallèle.
• Les conventions de commits rendent l’historique propre, maintenable et communicatif.

Vous venez d’apprendre comment travaillent les équipes d’ingénierie modernes.

---

Prochaine étape

Si Git permet de collaborer localement avec des branches, comment une équipe distribuée de développeurs peut-elle s’organiser, suivre son travail et coordonner des dizaines de contributions simultanément ?

Étape suivante : GitHub for Engineering Teams