Comment changer de branche dans GitHub

Changer de branche dans GitHub constitue une étape quotidienne pour organiser le travail collaboratif et isoler les fonctionnalités. Maîtriser les commandes comme checkout, rebase et merge permet d’éviter les conflits lors d’un pull request ou d’un merge.

Ce texte décrit les opérations locales et les actions sur le dépôt distant, en mettant l’accent sur les commandes pratiques et les bonnes pratiques. Je propose un repère synthétique pour préparer l’exécution des commandes, menant vers A retenir :

A retenir :

• Contrôle clair des branches locales, remotes et historiques de commit
• Réduction des conflits lors des merges et des pull requests
• Possibilité de développer des fonctionnalités isolées avant la fusion
• Sauvegarde des modifications en cours avant tout changement de branche

Changer de branche localement avec git checkout

À partir des points essentiels listés, la première étape consiste à comprendre la commande locale la plus fréquente. La maîtrise du checkout facilite le déplacement entre branches et le positionnement du HEAD sur un commit précis.

La bonne pratique est d’avoir des commits propres avant de changer de branche pour éviter les pertes et conflits. Ce souci de préparation prépare la gestion des branches depuis l’interface web de GitHub.

Commande git checkout et git switch

Cette section montre la différence d’usage entre git checkout et la commande plus récente git switch. Les deux commandes déplacent le HEAD, mais git switch clarifie l’intention quand il s’agit de basculer ou de créer une branche.

Commande	Usage courant	Crée nouvelle branche	Effet sur HEAD
git checkout BRANCHE	Basculer sur une branche existante	Non	Déplace HEAD vers la branche
git checkout -b NOM	Créer et basculer sur une nouvelle branche	Oui	HEAD attaché à la nouvelle branche
git switch BRANCHE	Basculer sur une branche existante (clarifié)	Non	Déplace HEAD de façon explicite
git switch -c NOM	Créer et basculer, alternative moderne	Oui	HEAD attaché à la nouvelle branche

Avant d’exécuter checkout, vérifier l’état du répertoire évite des surprises liées aux fichiers non indexés. Une simple sauvegarde ou un commit temporaire protège le travail en cours et simplifie le merge ultérieur.

Commandes essentielles Git :

• git status pour vérifier l’état du dépôt et des fichiers
• git add suivi de git commit pour sauvegarder les changements locaux
• git checkout -b nom-branche pour créer et basculer simultanément
• git switch -c nom-branche comme alternative moderne à checkout -b

« J’ai souvent créé une branche pour expérimenter sans impacter la main, puis j’ai fusionné proprement après tests. »

Alice D.

Gérer les branches distantes et le dépôt remote

En liaison avec la manipulation locale, il faut synchroniser les branches avec le remote pour partager le travail. Pousser une branche vers le remote permet d’ouvrir un pull request et d’engager une revue de code sur GitHub.

Selon GitHub Docs, la branche par défaut conditionne le flux des pull requests et des commits, et son changement requiert des droits administrateur. Selon Le Journal du Frreenaute, l’interface web facilite la sélection et la mise à jour de la branche par défaut pour un dépôt.

Push, fetch et suivi des branches distantes

Ce paragraphe décrit la séquence courante pour synchroniser une branche locale avec le dépôt distant. On effectue généralement git push pour envoyer une branche, et git fetch ou git pull pour récupérer les modifications depuis le remote.

Action	Commande	Effet
Envoyer une branche	git push origin nom-branche	Créer ou mettre à jour la branche sur le remote
Récupérer les refs	git fetch origin	Met à jour les branches distantes sans fusion
Récupérer et fusionner	git pull origin nom-branche	Récupère puis merge dans la branche courante
Suivre une branche distante	git branch –set-upstream-to	Lie la branche locale au remote

Actions distantes communes :

• Créer une branche locale puis git push pour la partager
• Configurer la branche upstream pour simplifier les pulls futurs
• Utiliser git fetch pour inspecter sans fusion automatique
• Supprimer une branche distante avec git push origin –delete

« J’ai résolu un conflit en local après un git pull, puis j’ai ouvert une pull request proprement. »

Marc L.

Modifier la branche par défaut sur GitHub

Selon GitHub, seuls les utilisateurs disposant d’un accès administrateur peuvent changer la branche par défaut d’un dépôt. La procédure passe par les paramètres du dépôt, la sélection d’une autre branche puis la confirmation familiale à la modification.

Avant ce changement, vérifier que la branche choisie contient l’historique attendu et que les pull requests ouvertes restent cohérentes. Ce contrôle évite des effets indésirables sur les workflows de CI/CD et les merges automatiques.

Bonnes pratiques pour fusionner, rebase et pull request

Le passage d’une gestion locale vers la revue en ligne impose des règles pour les pull request et le merge des branches. Adopter un flux clair réduit les risques et facilite la relecture du code avant l’intégration finale.

Selon Alphorm, préférer un rebase interactif pour nettoyer des commits locaux avant un merge aide à conserver un historique lisible. Selon Le Journal du Frreenaute, les équipes privilégient souvent des stratégies qui minimisent les conflits.

Stratégies de merge et utilisation du rebase

Ce point explique quand choisir un merge ou un rebase pour intégrer une branche dans main. Le merge conserve l’historique de branche tandis que le rebase refond les commits pour un historique linéaire.

Bonnes pratiques branche :

• Ecrire des commits atomiques et descriptifs avant toute fusion
• Utiliser rebase pour nettoyer les commits avant d’ouvrir une pull request
• Préférer merge quand l’historique de branche doit rester visible
• Faire une relecture de code obligatoire pour tout pull request majeur

« J’ai nettoyé mes commits via rebase puis j’ai demandé une relecture pour valider la fusion. »

Sophie R.

Exemples pratiques aident à appliquer ces règles, notamment pour résoudre les conflits lors d’un merge. Le respect de ces étapes facilite l’intégration et réduit le temps passé en résolution manuelle.

Validation d’une pull request et checklist

Cette sous-section liste les étapes concrètes pour valider une pull request dans GitHub. Une checklist inclut tests automatisés, revue de code, et vérification des conflits avant le merge final.

Actions de validation :

• Exécuter la suite de tests CI liée à la pull request
• Vérifier l’absence de conflits avec la branche cible
• Assurer la présence d’une revue approuvée par un pair
• Fermer ou relier les issues associées avant le merge

« Après la revue, nous avons fusionné puis observé les logs CI pour garantir la stabilité. »

Thomas B.

Une fiche de vérification standard réduit les erreurs humaines lors du merge, et encourage les bonnes pratiques. Ce point conclut les aspects opérationnels et oriente vers des ressources fiables pour approfondir.

Source : GitHub, « Changement de la branche par défaut », GitHub Docs, 2024 ; Alphorm, « Gestion efficace des branches avec Git », Alphorm, 2023 ; Le Journal du Frreenaute, « Comment changer de branche dans GitHub », Le Journal du Frreenaute, 2022.

Ressources vidéo et démonstrations

Pour compléter la lecture, des vidéos pas à pas montrent les commandes et l’interface graphique de GitHub. Ces démonstrations aident à visualiser la création, le push et l’ouverture d’un pull request depuis un dépôt distant.

Une autre ressource vidéo illustre la résolution de conflits après un pull et après un rebase, utile aux développeurs en 2025. L’observation de ces cas concrets accélère la maîtrise des procédures.

Commandes de réparation utiles :

• git stash pour sauvegarder temporairement les modifications non committées
• git rebase -i pour réécrire l’historique local avant push
• git merge –no-ff pour conserver une trace explicite du merge
• git reset –hard uniquement après sauvegarde sûre des changements