« Je veux tester sans rien casser »
Votre site fonctionne. En production, des gens l'utilisent. Et vous avez une idée : refaire complètement la page d'accueil. Mais si vous bidouillez directement dans le code en ligne, le moindre bug casse le site pour tout le monde, en plein milieu de votre expérimentation.
La solution n'est pas de recopier le dossier. C'est de créer une branche : un espace de travail parallèle où vous bricolez librement, pendant que la version stable reste intacte. Si votre idée est bonne, vous la fusionnez. Si elle est mauvaise, vous jetez la branche, et rien n'a bougé.
Le modèle mental : des lignes de temps parallèles
Imaginez l'historique de votre projet comme une ligne de temps. La branche principale s'appelle généralement main. Quand vous créez une branche, vous faites bifurquer une seconde ligne de temps à partir du présent :
main A---B---C
\
nouvelle-page D---ELes commits D et E vivent sur la branche nouvelle-page. La branche main ne les voit même pas : elle reste figée sur C, stable et fonctionnelle. Vous pouvez sauter d'une ligne de temps à l'autre quand vous voulez. Quand votre travail est prêt, vous le ramenez dans main par une fusion.
feature diverge de main, vit sa vie, puis la rejoint par une fusion.Créer, basculer, fusionner
Trois actions, une session complète :
$ git branch
* main
$ git switch -c nouvelle-page
Switched to a new branch 'nouvelle-page'
# ... vous éditez, vous ajoutez, vous committez sur cette branche ...
$ git add index.html
$ git commit -m "Refonte de la page d'accueil"
$ git switch main
Switched to branch 'main'
$ git merge nouvelle-page
Updating c3d4e5f..a1b2c3d
Fast-forward
index.html | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)git branch liste les branches (l'étoile marque la branche active). git switch -c nom crée une branche et bascule dessus d'un coup (l'ancienne syntaxe était git checkout -b nom, encore très répandue). git switch main revient sur la branche principale. git merge ramène les commits de l'autre branche dans la branche courante.
Une branche par fonctionnalité
La discipline qui rend les branches vraiment utiles : ne jamais travailler directement sur main. Chaque nouvelle fonctionnalité, chaque correction de bug, mérite sa propre branche.
Des noms parlants aident toute l'équipe : feature/panier-paiement, fix/email-invalide, refonte/page-accueil. On lit le but de la branche d'un coup d'œil.
Bonne pratique : une branche par fonctionnalité, et main toujours dans un état déployable. Ainsi, à tout moment, la branche principale est saine et prête à partir en production, pendant que le travail en cours reste isolé dans ses propres branches.
"I want to test without breaking anything"
Your site works. In production, people are using it. And you have an idea: completely rebuild the homepage. But if you tinker directly in the live code, the slightest bug breaks the site for everyone, right in the middle of your experiment.
The solution is not to copy the folder. It is to create a branch: a parallel workspace where you tinker freely, while the stable version stays intact. If your idea is good, you merge it. If it is bad, you throw the branch away, and nothing moved.
The mental model: parallel timelines
Picture your project's history as a timeline. The main branch is usually called main. When you create a branch, you fork a second timeline starting from the present:
main A---B---C
\
new-page D---ECommits D and E live on the new-page branch. The main branch does not even see them: it stays frozen on C, stable and working. You can jump from one timeline to the other whenever you want. When your work is ready, you bring it back into main with a merge.
feature branch diverges from main, lives its life, then rejoins it through a merge.Create, switch, merge
Three actions, one complete session:
$ git branch
* main
$ git switch -c new-page
Switched to a new branch 'new-page'
# ... you edit, you add, you commit on this branch ...
$ git add index.html
$ git commit -m "Rebuild the homepage"
$ git switch main
Switched to branch 'main'
$ git merge new-page
Updating c3d4e5f..a1b2c3d
Fast-forward
index.html | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)git branch lists the branches (the star marks the active one). git switch -c name creates a branch and switches to it at once (the older syntax was git checkout -b name, still very common). git switch main returns to the main branch. git merge brings the other branch's commits into the current one.
One branch per feature
The discipline that makes branches truly useful: never work directly on main. Each new feature, each bug fix, deserves its own branch.
Meaningful names help the whole team: feature/cart-checkout, fix/invalid-email, redesign/homepage. You read the branch's purpose at a glance.
Best practice: one branch per feature, and main always in a deployable state. That way, at any moment, the main branch is healthy and ready to ship to production, while work in progress stays isolated in its own branches.
Perdu entre git switch, git checkout et git restore ? Demandez à l'IA de clarifier :
Je débute avec les branches Git. Explique-moi en français, avec un exemple concret pour chacune, la différence entre git switch, git checkout et git restore, et dans quel cas utiliser laquelle aujourd'hui. Précise aussi quelle est l'ancienne syntaxe et laquelle est recommandée maintenant.
Sans relire la réponse de l'IA : avec tes mots, à quoi sert git switch et pourquoi on le préfère aujourd'hui à git checkout pour changer de branche ?
git switch sert uniquement à changer de branche (et -c en crée une au passage). git checkout faisait tout à la fois (changer de branche ET restaurer des fichiers), ce qui prêtait à confusion et provoquait des erreurs. Git a donc séparé le rôle en deux commandes claires : switch pour les branches, restore pour annuler des modifs de fichiers. checkout marche encore mais switch est plus lisible.Écrivez les commandes pour : créer une branche nommée nouvelle-page et basculer dessus, puis (après vos commits) revenir sur main et fusionner la branche. Utilisez git switch -c, git switch main et git merge.
Tu veux travailler ta refonte de page d'accueil sans risque. L'IA te propose cette suite de commandes. Ton rôle de relecteur : l'accepter telle quelle ou la rejeter, et dire pourquoi.
$ git switch main
$ git add index.html
$ git commit -m "maj"
$ git pushmain : c'est exactement ce que la leçon dit de ne jamais faire (il fallait git switch -c refonte/page-accueil d'abord). Ensuite le message "maj" ne dit rien : dans six mois personne, toi compris, ne saura ce que faisait ce commit. La bonne version : créer une branche dédiée, puis un message parlant comme "Refonte de la page d'accueil".Sans remonter dans la leçon : quelle commande crée une branche et bascule dessus d'un coup, et que fait git merge nouvelle-page quand tu es sur main ?
git switch -c nouvelle-page crée la branche nouvelle-page et bascule dessus en une seule commande. Une fois revenu sur main avec git switch main, git merge nouvelle-page ramène les commits de nouvelle-page dans main (la branche courante), réunissant les deux lignes de temps.Vous créez, basculez et fusionnez des branches comme un pro. Mais tout cela vit encore sur votre seul ordinateur : et s'il tombe en panne ? La prochaine leçon vous connecte à GitHub pour cloner, pousser et tirer votre code vers un dépôt distant.
Leçon 6 : GitHub et le dépôt distant →