Créer et changer de branche Git : choisissez le bon point de départ

Utilisez `git switch -c feature/checkout` pour créer une branche sur votre commit actuel et y basculer. Pour passer à une branche locale existante, utilisez git switch branch-name. Pour en créer un à un point de départ différent, incluez ce commit ou cette branche après le nouveau nom. Dans GitTree, Branch ouvre la boîte de dialogue de création ; vérifiez son commit de départ avant de confirmer.

La question pratique est de savoir sur quelle histoire votre prochain changement devrait s’appuyer. Une fonctionnalité de la prochaine version pourrait démarrer à partir de la version principale ; un correctif urgent pour une version plus ancienne doit démarrer à partir de cette branche de version. Ce guide suit une branche de fonctionnalité depuis sa base jusqu'à sa première poussée, avec un exemple animé GitTree. GitTree est le client que nous créons pour macOS, Windows et Linux ; Les opérations des succursales locales sont incluses dans le plan gratuit et les versions officielles actuelles nécessitent une connexion.

Qu'est-ce qu'une branche Git et que signifie HEAD ?

Une branche est un nom pointant vers un commit. La création d'un autre nom ne duplique pas le référentiel ou ses fichiers. HEAD identifie normalement la branche que vous avez extraite ; les nouveaux commits font avancer cette branche. Le basculement modifie les fichiers extraits vers l’historique de destination tout en préservant les modifications locales compatibles. Un graphique de validation visuel facilite l'inspection des étiquettes de branche et de leurs validations partagées.

Créer une branche à partir de la bonne base

Inspectez d’abord la branche actuelle et les modifications locales. Si votre équipe souhaite que le dernier main récupéré soit la base, récupérez et nommez origin/main explicitement. Récupérer les mises à jour des références de suivi à distance ; cela ne déplace pas automatiquement votre principal local. Remplacez origin, main et le nom de la fonctionnalité par les noms réels du référentiel.

git status
git branch --show-current
git fetch origin
git log -1 --oneline origin/main
git switch --no-track -c feature/checkout origin/main
git branch --show-current
git log -1 --oneline

Ici, --no-track évite que la branche de fonctionnalité suive l'origine/la principale simplement parce qu'elle commence là. Son éventuel amont devrait normalement être sa propre branche de fonctionnalités sur la télécommande. Si vous souhaitez plutôt commencer à partir du commit actuel, utilisez git switch -c feature/checkout sans point de départ. Utilisez git branch -vv pour inspecter les relations de suivi.

Basculer vers une branche existante et revenir à la précédente

git switch feature/checkout
git branch --show-current
git switch -

Exécutez chaque commutateur lorsque vous souhaitez réellement modifier les tâches ; ces commandes sont une référence et non des étapes à exécuter aveuglément. git switch - revient à la branche ou au commit précédemment extrait. Le commutateur Git est disponible à partir de Git 2.23 ; sur les installations plus anciennes, git checkout branch-name est l'équivalent établi pour changer de branche. N'ajoutez jamais d'option de force simplement pour faire taire un refus.

Télécharger GitTree pour voir les branches et leurs commits de départ avant de changer. Votre référentiel reste un référentiel Git normal, vous pouvez donc vous déplacer entre l'interface visuelle et les commandes du terminal.

Qu'arrive-t-il aux modifications non validées lors du changement de branche ?

Les modifications non validées ne sont pas encore stockées sur une branche. Git peut les transporter via un commutateur lorsqu'ils sont compatibles avec la destination. Il s'arrête si le commutateur écrase les modifications locales. Ce refus protège le travail ; cela ne signifie pas que le référentiel est cassé. Vérifiez git status avant et après le changement plutôt que de supposer que chaque modification appartient à la branche sur laquelle vous vous trouviez.

GitTree propose Stash et Switch, Commit First, et Discard and Switch lorsque les modifications locales bloquent l'extraction. Choisissez l'option qui correspond à votre intention. Stashing conserve une copie locale temporaire ; la validation enregistre un instantané dans l'historique ; la suppression supprime les modifications de travail. Ne choisissez pas Supprimer comme moyen habituel de changer de branche. Le guide de cachette explique comment inspecter et restaurer le travail enregistré.

Créer une branche locale à partir d'une branche distante

git fetch origin
git branch --remotes
git switch -c feature/checkout --track origin/feature/checkout
git branch -vv

Cet exemple suppose que la branche fonctionnalité/extraction locale n'existe pas encore et que la branche distante existe. S'il existe déjà localement, passez-y au lieu d'essayer de le créer à nouveau. Un nom de suivi à distance tel que origin/feature/checkout est votre dernière vue récupérée de la branche du serveur ; la succursale locale est l'endroit où vous vous engagez. Le suivi ne synchronise pas les fichiers en continu.

Publiez votre nouvelle branche lorsque le changement est prêt

git status
git branch --show-current
git push -u origin feature/checkout

La création d'une branche locale ne la télécharge pas. Après avoir examiné et validé les modifications prévues, poussez la branche à partager ses validations ; -u enregistre la relation en amont. Confirmez la télécommande de destination et la branche avant le premier push. Pour un flux de travail de téléchargement plus large, consultez pousser un projet vers GitHub. Un push ne publie pas de modifications non validées sans rapport ni d'entrées de cache locales.

Corrigez les erreurs de branche courantes sans forcer le commutateur

Si vous avez uniquement modifié sur la mauvaise branche sans vous engager, la création d'une nouvelle branche au niveau du HEAD actuel vous permet souvent d'y poursuivre ces modifications. Si vous avez déjà validé le correctif, le transférer est une tâche différente : le cherry-pick guide explique la copie du commit choisi. Pour deux tâches actives, utilisez des arbres de travail séparés afin que le changement d'un dossier n'interrompe pas l'autre.