Français ▾ Topics ▾ Latest version ▾ git-checkout last updated in 2.52.0

NOM

git-checkout - Bascule sur une autre branche ou restaure des fichiers de l’arbre de travail

SYNOPSIS

git checkout [-q] [-f] [-m] [<branche>]
git checkout [-q] [-f] [-m] --detach [<branche>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <nouvelle-branche>] [<point-de-départ>]
git checkout <arbre-esque> [--] <spec-de-chemin>…​
git checkout <arbre-esque> --pathspec-from-file=<fichier> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <spec-de-chemin>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<fichier> [--pathspec-file-nul]
git checkout (-p|--patch) [<arbre-esque>] [--] [<spec-de-chemin>…​]

DESCRIPTION

git checkout a deux modes principaux :

  1. Basculer de branche, avec git checkout <branche>

  2. Restaurer une autre version d’un fichier, par exemple avec git checkout <commit> <nom-de-fichier> ou git checkout <nom-de-fichier>

Voir DÉSAMBIGUÏSATION D’ARGUMENT ci-dessous pour la façon dont Git décide lequel utiliser.

git checkout [<branche>]

Passage à <branche>. Cela définit la branche actuelle à _ <branche>_ et met à jour les fichiers dans votre répertoire de travail. L’extraction échouera s’il n’y a des changements non validés dans les fichiers où < branche> et votre commit actuel ont un contenu différent. Les changements non validés seront conservés sinon.

Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant et --no-guess n’est pas spécifié, le traiter comme équivalent à

$ git checkout -b <branche> --track <distant>/<branche>

Lancer git checkout sans spécifier une branche n’a aucun effet sauf pour afficher les informations de suivi pour la branche actuelle.

git checkout -b <nouvelle-branche> [<point-de-départ>]

Créer une nouvelle branche nommée <nouvelle-branche>, la commencer à <point-de-départ> (par défaut le commit actuel), et basculer sur cette nouvelle branche. Vous pouvez utiliser les options --track ou --no-track pour renseigner l’information de suivi amont de cette branche.

Cela échouera s’il y a une erreur lors de l’extraction de <nouvelle-branche>, par exemple si extraire le commit _<point-de-départ> écraserait vos changements non validés.

git checkout -B <nouvelle-branche> [<point-de-départ>]

La même chose que -b, sauf que si la branche existe déjà, Git réinitialise <branche> au point de départ au lieu d’échouer.

git checkout --detach [<branche>]
git checkout [--detach] <commit>

La même chose que git checkout <branche>, sauf que, au lieu de pointer HEAD sur la branche, pointe HEAD à l’ID de commit. Voir la section HEAD DÉTACHÉE ci-dessous pour plus de détails.

Omettre <branche> détache HEAD au sommet de la branche actuelle.

git checkout <arbre-esque> [--] <spéc-de-chemin>...
git checkout <arbre-esque> --pathspec-from-file=<fichier> [--pathspec-file-nul]

Remplacer les fichiers et/ou les répertoires spécifiés par la version du commit ou de l’arbre donné et les ajouter à l’index (également connu sous le nom de « zone de préparation »).

Par exemple, git checkout main fichier.txt remplacera fichier.txt par sa version dans main.

git checkout [-f | --ours | --theirs | -m | --conflict=<style>] [--] <spéc-de-chemin>...
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<fichier> [--pathspec-file-nul]

Remplacer les fichiers et/ou les répertoires spécifiés par la version de l’index.

Par exemple, si vous extrayez un commit, puis modifiez fichier.txt, puis décidez que ces changements étaient une erreur, git checkout fichier.txt va supprimer tout changement non indexé dans fichier.txt.

Cela échouera si le fichier a un conflit de fusion et vous n’avez pas encore lancé git add fichier.txt (ou quelque chose d’équivalent) pour le marquer comme résolu. Vous pouvez utiliser -f pour ignorer les fichiers non fusionnés au lieu d’échouer, utiliser --ours ou --theirs pour les remplacer par la version d’un côté spécifique de la fusion, ou utiliser -m pour les remplacer par le résultat original du conflit de fusion.

git checkout (-p|--patch) [<arbre-esque>] [--] [<spéc. de chemin>...]

C’est similaire aux deux modes précédents, mais vous laisse utiliser l’interface interactive pour afficher la sortie « diff » et choisir quelles sections utiliser dans le résultat. Voir plus bas la description de l’option --patch.

OPTIONS

-q
--quiet

Silencieux, supprimer les messages d’état.

--progress
--no-progress

L’état d’avancement est affiché sur la sortie standard d’erreur par défaut quand elle est attachée à un terminal, à moins que --quiet ne soit spécifié. Cette bascule active l’état d’avancement même sans être attaché à un terminal, indépendamment de --quiet.

-f
--force

Lors du basculement de branche, continuer même si l’index ou l’arbre de travail sont différents de HEAD, et même s’il y a des fichiers non-suivis qui bloquent.Ceci peut servir à éliminer des modifications locales ainsi que tous les fichiers ou répertoires non-suivis qui gênent.

Lors de l’extraction de chemins depuis l’index, ne pas échouer sur des entrées non fusionnées ; à la place, les entrées non fusionnées sont ignorées.

--ours
--theirs

Lors de l’extraction de chemins depuis l’index, extraire l’état #2 (ours, le nôtre) ou #3 (theirs, le leur) pour les chemins non fusionnés.

Veuillez noter que pendant git rebase et git pull --rebase, ours et theirs peuvent sembler échangés ; --ours fournit la version depuis la branche sur laquelle les modifications sont rebasées, tandis que --theirs fournit la version de la branche qui contient le travail rebasé.

C’est parce que rebase est utilisé dans une approche qui traite l’historique distant comme la référence canonique partagée, et traite le travail sur la branche que vous rebasez comme un travail tiers à intégrer, et vous endossez temporairement le rôle du gardien de l’historique canonique quand vous rebasez. En tant que gardien de l’historique canonique, vous devez voir l’historique distant comme le vôtre (ours, c’est-à-dire « notre historique partagé canonique »), tandis que votre travail sur l’autre branche devient le tiers (theirs, c’est-à-dire « le travail d’un contributeur sur le canonique »).

-b <nouvelle-branche>

Créer une nouvelle branche nommée <nouvelle-branche>, la commencer à <point-de-départ> et extraire la branche résultante ; voir git-branch[1] pour plus de détails.

-B <nouvelle-branche>

La même chose que -b, sauf que si la branche existe déjà, Git réinitialise <branche> au point de départ au lieu d’échouer.

-t
--track[=(direct|inherit)]

À la création d’une nouvelle branche, établir la configuration upstream (branche amont). Voir --track dans git-branch[1] pour plus de détails. Par commodité, --track sans -b implique la création de la branche.

Si aucune option -b n’est fournie, le nom de la nouvelle branche sera dérivé de la branche de suivi à distance, en regardant la partie locale de la spécification de référence configurée pour le distant correspondant et en enlevant la partie initiale jusqu’au "*". Cela indiquerait d’utiliser le nom « hack » comme branche locale créée à partir de origin/hack (ou remotes/origin/hack, ou même refs/remotes/origin/hack). Si le nom fourni ne contient pas de barre oblique, ou si le résultat de la dérivation est un nom vide, la dérivation échoue. Vous pouvez spécifier explicitement un nom avec -b dans ce cas.

--no-track

Ne pas renseigner la configuration « amont », même si la configuration branch.autoSetupMerge est true.

--guess
--no-guess

Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant, le traiter comme équivalent à

$ git checkout -b <branche> --track <distant>/<branche>

Si la branche existe dans plus d’un distant et que l’un d’entre eux est la valeur de la variable de configuration checkout.defaultRemote, celui-ci sera utilisé pour désambiguïser, même si la <branche> n’est pas unique parmi tous les distants. Réglez la variable checkout.defaultRemote=origin par exemple pour extraire toujours les branches distantes depuis celle-ci si <branche> est ambigüe mais existe sur le distant origin. Voir aussi checkout.defaultRemote dans git-config[1].

--guess est le comportement par défaut. Utilisez --no-guess pour le désactiver.

Le comportement par défaut peut être défini via la variable de configuration checkout.guess.

-l

Créer le reflog de la nouvelle branche ; voir git-branch[1] pour plus de détails.

-d
--detach

Plutôt que d’extraire une branche pour travailler dessus, extraire un commit pour l’inspecter et faire des expériences jetables. C’est le comportement par défaut de git checkout <commit> quand <commit> n’est pas un nom de branche. Voir la section « HEAD DÉTACHÉE » plus bas pour plus de détails.