– qquietquiet
Quiet, supprime les messages de retour.
progressprogressnono-progress
L’état de progression est signalé sur le flux d’erreur standard par défaut lorsqu’il est attaché à un terminal, sauf si --quiet est spécifié. Cet indicateur active les rapports de progression même s’ils ne sont pasattachés à un terminal, indépendamment de --quiet.
-fforceforce
Lors du changement de branches, procédez même si l’index ou l’arbre de travail diffère de HEAD. Ceci est utilisé pour jeter les changements locaux.
Lors de l’extraction des chemins de l’index, n’échouez pas sur les entrées non fusionnées ; à la place, les entrées non fusionnées sont ignorées.
oursle nôtre e leur
Lors de la vérification des chemins de l’index, consultez l’étape #2 (la nôtre) ou #3 (la leur) pour les chemins non fusionnés.
Notez que pendant git rebase et git pull --rebase, les nôtres et les numéros peuvent apparaître échangés; --ours donne la version de la branche sur laquelle les modifications sont rebasées, tandis que --theirs donne la version de la branche qui contient votre travail en cours de rebasage.
En effet, rebase est utilisé dans un flux de travail qui traite l’histoire à distance comme celle canonique partagée, et traite le travail effectué sur la branche que vous rebasez comme le travail tiers à intégrer, et vous assumez temporairement le rôle de gardien de l’historique canonique pendant le rebasage. En tant que gardien de l’histoire canonique, vous devez afficher l’histoire à partir de la distance ours (c’est-à-dire « notre histoire canonique partagée »), tandis que ce que vous faisiez sur votre branche latérale en tant que theirs (c’est-à-dire » le travail d’un contributeur à ce sujet « ).
-b <new_branch >
Créez une nouvelle branche nommée <new_branch> et démarrez-la à <start_point>; voir git-branch pour plus de détails.
-B <new_branch>-ttracktrack
Lors de la création d’une nouvelle branche, configurez la configuration « en amont ». Voir « tracktrack » dans git-branch pour plus de détails.
Si aucune option -b n’est donnée, le nom de la nouvelle branche sera supprimé de la branche de suivi à distance, en examinant la partie locale de la refspec configurée pour la télécommande correspondante, puis en supprimant la partie initiale jusqu’au « * ».Cela nous indiquerait d’utiliser hack comme branche locale lors de la dérivation de origin/hack (ou remotes/origin/hack, ou même refs/remotes/origin/hack). Si le prénom n’a pas de barre oblique, ou si le résultat ci-dessus donne un nom vide, la supposition est abandonnée. Vous pouvez donner explicitement un nom avec -b dans un tel cas.
nono-track
Ne configurez pas la configuration « en amont », même si la variable de configuration branch.autoSetupMerge vaut true.
guessguessnono-guess
Si <branch> n’est pas trouvé mais qu’il existe un trackingbranch dans exactement une télécommande (appelez-le <remote>) avec un nom d’amatching, traitez-le comme équivalent à
$ git checkout -b <branch> --track <remote>/<branch>
Si la branche existe dans plusieurs télécommandes et que l’une d’elles est nommée par la variable de configuration checkout.defaultRemote, nous utiliserons celle-ci à des fins de désambiguïsation, même si la <branch> n’est pas unique sur toutes les télécommandes. Mets-le aux pieds.g. checkout.defaultRemote=origin pour toujours extraire les ramifications distantes à partir de là si <branch> est ambigu mais existe sur la télécommande. Voir aussi checkout.defaultRemoteingit-config.
--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ée le reflog de la nouvelle branche ; voir git-branch fordetails.
-ddetdetach
Plutôt que de vérifier une branche pour y travailler, consultez acommit pour l’inspection et les expériences éliminables.C’est le comportement par défaut de git checkout <commit> lorsque <commit> n’est pas un nom de branche. Voir la section « TÊTE DÉTACHÉE » ci-dessous pour plus de détails.
orphanorphan <new_branch >
Créez une nouvelle branche orpheline, nommée <new_branch>, démarrée à partir de <start_point> et passez-y. Le premier commit effectué sur cette nouvelle branche n’aura pas de parents et sera la racine d’une nouvelle histoire totalement déconnectée de toutes les autres branches et engagements.
L’index et l’arborescence de travail sont ajustés comme si vous aviez précédemment exécuté git checkout <start_point>. Cela vous permet de démarrer un nouvel histoirequi enregistre un ensemble de chemins similaires à <start_point> en exécutant facilement git commit -a pour effectuer la validation racine.
Cela peut être utile lorsque vous souhaitez publier l’arborescence à partir d’un commitsans exposer son historique complet. Vous voudrez peut-être le faire pour publierune branche open source d’un projet dont l’arborescence actuelle est « propre », mais dont l’historique complet contient des bits de code propriétaires ou autrement grevés.
Si vous souhaitez démarrer un historique déconnecté qui enregistre un ensemble de chemins totalement différents de celui de <start_point>, vous devriezdéclarer l’index et l’arbre de travail juste après la création de la branche orpheline en exécutant git rm -rf . à partir du niveau supérieur de l’arbre de travail.Ensuite, vous serez prêt à préparer vos nouveaux fichiers, à repeupler l’arbre de travail, en les copiant d’ailleurs, en extrayant une archive, etc.
ignoreignore-skip-worktree-bits
En mode de paiement clairsemé, git checkout -- <paths> ne mettrait à jour que les entrées correspondant à <paths> et à des motifs clairsemés dans $GIT_DIR/info/sparse-checkout. Cette option ignore les motifs épars et ajoute tous les fichiers dans <paths>.
-mmergemerge
Lors du changement de branche, si vous avez des modifications locales à un ou plusieurs fichiers différents entre la branche courante et la branche vers laquelle vous basculez, la commande refuse de changer de branche afin de préserver vos modifications dans le contexte.Cependant, avec cette option, une fusion à trois voies entre la branche actuelle, le contenu de votre arbre de travail et la nouvelle branche est terminée, et vous serez sur la nouvelle branche.
Lorsqu’un conflit de fusion se produit, les entrées d’index des chemins de conflit ne sont pas fusionnées et vous devez résoudre les conflits et marquer les chemins résolus avec git add (ou git rm si la fusion doit entraîner la suppression du chemin).
Lors de l’extraction des chemins de l’index, cette option vous permet de recréer la fusion en conflit dans les chemins spécifiés.
Lors du changement de branches avec --merge, les modifications échelonnées peuvent être perdues.
conflictconflict=<style >
Identique à l’option --merge ci-dessus, mais change la façon dont les hunks conflictuels sont présentés, remplaçant le merge.conflictStyle variable de configuration. Les valeurs possibles sont « merge » (par défaut) et « diff3 » (en plus de ce qui est montré par le style « merge », montre le contenu d’origine).
-ppatchpatch
Sélectionnez de manière interactive les morceaux dans la différence entre le <tree-ish> (ou l’index, si non spécifié) et le workingtree. Les hunks choisis sont ensuite appliqués en sens inverse à l’arborescence de travail (et si un <tree-ish> a été spécifié, l’index).
Cela signifie que vous pouvez utiliser git checkout -p pour éliminer sélectivement les éléments de votre arborescence de travail actuelle. Reportez-vous à la section ”Mode interactif » de git-add pour apprendre à utiliser le mode --patch.
Notez que cette option utilise le mode sans superposition par défaut (voir également --overlay) et ne prend actuellement pas en charge le mode de superposition.
ignoreignore-other-worktrees
git checkout refuse lorsque la référence souhaitée est déjà vérifiée par un autre arbre de travail. Cette option permet de vérifier le refout de toute façon. En d’autres termes, la réf peut être détenue par plus d’untree de travail.
overoverwrite-ignorenono-overwrite-ignore
Écrase silencieusement les fichiers ignorés lors du changement de branche. C’est le comportement par défaut. Utilisez --no-overwrite-ignore pour interrompre l’opération lorsque la nouvelle branche contient des fichiers ignorés.
norecurse-submodulesnono-recurse-submodules
En utilisant --recurse-submodules mettra à jour le contenu de tous les sous-modules activesubmodules en fonction de la validation enregistrée dans le superproject. Si les modifications locales dans un sous-module sont écrasées, la commande échouera à moins que -f ne soit utilisée. Si rien (ou --no-recurse-submodules) n’est utilisé, les sous-modules fonctionnant dans les arbres ne seront pas mis à jour.Tout comme git-submodule, cela détachera HEAD du sous-module.
overlayoverlaynono-overlay
Dans le mode de superposition par défaut, git checkout ne supprime jamais les fichiers de l’index ou de l’arborescence de travail. Lorsquepécifiant --no-overlay, les fichiers qui apparaissent dans l’index et l’arborescence de travail, mais pas dans <tree-ish> sont supprimés, pour les faire correspondre exactement <tree-ish>.
pathpathspec-from-file=<file >
Pathspec est passé dans <file> au lieu des arguments de ligne de commande. Si <file> est exactement - alors l’entrée standard est utilisée. Les éléments de chemin sont séparés par LF ou CR/LF. Les éléments Pathspec peuvent être cités comme expliqué pour la variable de configuration core.quotePath (voir git-config). Voir aussi --pathspec-file-nul etglobal --literal-pathspecs.
pathpathspec-file-nul
Seulement significatif avec --pathspec-from-file. Les éléments Pathspec sont séparés par un caractère NUL et tous les autres caractères sont pris littéralement (y compris les sauts de ligne et les guillemets).
<branch >
Branch to checkout; s’il fait référence à une branche (c’est-à-dire un nom qui, lorsqu’il est ajouté avec « refs/heads/ », est une référence valide), alors cette branche est extraite. Sinon, s’il fait référence à un validcommit, votre HEAD devient « détaché » et vous n’êtes plus sur aucune branche (voir ci-dessous pour plus de détails).
Comme cas particulier, vous pouvez utiliser A...Bcomme raccourci pour la base de fusion de A et B s’il y a exactement une base de fusion. Vous pouvez laisser au plus l’un des A et B, auquel cas il vaut par défaut HEAD.
<new_branch >
Nom de la nouvelle branche.
<start_point >
Le nom d’un commit auquel démarrer la nouvelle branche ; seegit-branch pour plus de détails. Par défaut, HEAD.
Comme cas particulier, vous pouvez utiliser "A...B"comme raccourci pour la base de fusion de A et B s’il y a exactement une base de fusion. Vous pouvez laisser au plus l’un des A et B, auquel cas il vaut par défaut HEAD.
<arbre-ish >
Arbre à extraire (lorsque les chemins sont donnés). S’il n’est pas spécifié, l’index sera utilisé.
Comme cas particulier, vous pouvez utiliser "A...B"comme raccourci pour la base de fusion de A et B s’il y a exactement une base de fusion. Vous pouvez laisser au plus l’un des A et B, auquel cas il vaut par défaut HEAD.
—
N’interprétez plus d’arguments comme des options.
<pathspec >Limits
Limite les chemins affectés par l’opération.
Pour plus de détails, voir l’entrée pathspec dans gitglossary.