– q quiet silencioso
Silencioso, suprime los mensajes de retroalimentación.
progress progress no sin progreso
El estado de progreso se informa en la secuencia de errores estándar por defecto cuando se adjunta a un terminal, a menos que se especifique --quiet. Este indicador habilita los informes de progreso incluso si no están conectados a un terminal, independientemente de --quiet.
– f force fuerza
Al cambiar ramas, proceda incluso si el índice o el árbol de trabajo difieren de HEAD. Esto se usa para evitar cambios locales.
Al comprobar las rutas del índice, no falle en las entradas no fusionadas; en su lugar, las entradas no fusionadas se ignoran.
urs l suyo
Al revisar rutas desde el índice, echa un vistazo a la etapa # 2 (la nuestra) o #3 (la suya) para rutas sin fusionar.
Tenga en cuenta que durante git rebase y git pull --rebase, las nuestras y las suyas pueden aparecer intercambiadas; --ours da la versión de la rama en la que se vuelven a basar los cambios, mientras que --theirs da la versión de la rama que contiene tu trabajo que se está rebasando.
Esto se debe a que rebase se utiliza en un flujo de trabajo que trata la historia en el control remoto como la canónica compartida, y trata el trabajo realizado en la rama que está reorganizando como el trabajo de terceros a integrar, y está asumiendo temporalmente el papel de guardián del historial canónico durante la reorganización. Como guardián del historial canónico, debe ver el historial desde el remoto como ours (es decir, «nuestro historial canónico compartido»), mientras que lo que hizo en su rama lateral como theirs (es decir, «one contributor’s work on topof it»).
-b <new_branch>
Crear una nueva rama llamada <new_branch> y empezar a<start_point>; véase git-sucursal para más detalles.
– B < new_branch>- t track track
Al crear una nueva rama, configure la configuración» ascendente». Consulte»track track» en git-branch para obtener más detalles.
Si no se da la opción -b, el nombre de la nueva rama se obtendrá de la rama de seguimiento remoto, mirando la parte local del refspec configurado para el control remoto correspondiente, y luego separando la parte inicial hasta el «*».Esto nos diría el uso de hack como la rama local cuando branchingoff de origin/hack (o remotes/origin/hack, o inclusorefs/remotes/origin/hack). Si el nombre dado no tiene barra diagonal, o el resultado de la búsqueda anterior es un nombre vacío, la suposición se aborta. En tal caso, puede dar un nombre de forma explícita con -b.
no no-track
No configure la configuración «ascendente», incluso si la variable de configuraciónbranch.autoSetupMerge es verdadera.
–supongo –no-supongo
Si <branch> no se encuentra, pero sí existe un trackingbranch en exactamente un control remoto (llamada <remote>) con amatching nombre, tratar como equivalente a
$ git checkout -b <branch> --track <remote>/<branch>
Si la rama existe en varios mandos a distancia y uno de ellos es nombrado por el checkout.defaultRemote variable de configuración, vamos a utilizar a aquél a efectos de desambiguación, incluso si la etiqueta <branch> ¿’tunique a través de todos los mandos. Ponlo en el pie.g. checkout.defaultRemote=originpara verificar siempre las ranuras remotas desde allí si <branch> es ambiguo pero existe en theorigin remote. Véase también checkout.defaultRemote ingit-config.
--guess es el comportamiento predeterminado. Use --no-guess para deshabilitarlo.
El comportamiento predeterminado se puede establecer a través de la variable de configuración checkout.guess.
– l
Crear el reflog de la nueva rama; consulte git-branch fordetails.
– d det separar
En lugar de consultar una rama para trabajar en ella, consulte un compromiso para la inspección y los experimentos descartables.Este es el comportamiento predeterminado de git checkout <commit> cuando<commit> no es un nombre de rama. Consulte la sección» CABEZA SEPARADA » a continuación para obtener más detalles.
orphan orphan < new_branch>
Cree una nueva rama huérfana, llamada <new_branch>, iniciada desde<start_point> y cambie a ella. El primer commit hecho en esta nueva rama no tendrá padres y será la raíz de una nueva historia totalmente desconectada de todas las otras ramas y compromisos.
El índice y el árbol de trabajo se ajustan como si hubiera ejecutado previamentegit checkout <start_point>. Esto le permite iniciar un nuevo historial que registra un conjunto de rutas similares a <start_point> ejecutando fácilmentegit commit -a para hacer la confirmación de root.
Esto puede ser útil cuando desea publicar el árbol desde una confirmación sin exponer su historial completo. Es posible que desee hacer esto para publicar una rama de código abierto de un proyecto cuyo árbol actual es «limpio», pero cuyo historial completo contiene bits de código propietarios o gravados de otro modo.
Si desea iniciar un historial desconectado que registre un conjunto de rutas que sea totalmente diferente de la de <start_point>, debe borrar el índice y el árbol de trabajo justo después de crear la rama huérfana ejecutando git rm -rf . desde el nivel superior del árbol de trabajo.Después estará listo para preparar sus nuevos archivos, repoblando el árbol de trabajo, copiándolos de otro lugar, extrayendo un archivo comprimido, etc.
ignore ignore-skip-worktree-bits
En el modo de pago disperso, git checkout -- <paths> solo actualizará las entradas que coincidan con <paths> y patrones dispersos en $GIT_DIR/info/sparse-checkout. Esta opción ignora los patrones dispersos y agrega de nuevo cualquier archivo en <paths>.
– m merge merge
Al cambiar de rama, si tiene modificaciones locales en uno o más archivos que son diferentes entre la rama actual y la rama a la que está cambiando, el comando rechaza cambiar de rama para preservar sus modificaciones en contexto.Sin embargo, con esta opción, se realiza una combinación de tres vías entre la rama actual, el contenido de su árbol de trabajo y la nueva rama, y estará en la nueva rama.
Cuando se produce un conflicto de fusión, las entradas de índice de las rutas de conflicto se dejan sin fusionar, y debe resolver los conflictos y marcar las rutas resueltas con git add(o git rm si la fusión debería dar lugar a la eliminación de la ruta).
Al comprobar rutas desde el índice, esta opción le permite volver a crear la fusión en conflicto en las rutas especificadas.
Al cambiar ramas con --merge, los cambios por etapas pueden perderse.
conflict conflict=<style>
Lo mismo que --merge la opción anterior, pero cambia la forma en que se presentan los bloques conflictivos, anulando elmerge.conflictStyle variable de configuración. Los valores posibles son» merge «(predeterminado) y» diff3″(además de lo que se muestra con el estilo» merge», muestra el contenido original).
– p patch parche
Selecciona de forma interactiva trozos en la diferencia entre<tree-ish> (o el índice, si no se especifica) y el árbol de trabajo. Los trozos elegidos se aplican a la inversa al árbol de trabajo (y si se especificó un <tree-ish>, el índice).
Esto significa que puede usar git checkout -p para descartar selectivamente los datos de su árbol de trabajo actual. Consulte la sección»Modo interactivo»de git-add para aprender a operar el modo --patch.
Tenga en cuenta que esta opción utiliza el modo sin superposición de forma predeterminada (consulte también--overlay) y actualmente no admite el modo de superposición.
ignore ignore-other-worktrees
git checkout se niega cuando la referencia deseada ya está comprobada por otro worktree. Esta opción hace que compruebe la reposición de todos modos. En otras palabras, el ref puede ser sostenido por más de un árbol de trabajo.
over sobrescribir-ignorar no no-sobrescribir-ignorar
Sobrescribir silenciosamente los archivos ignorados al cambiar de rama. Este es el comportamiento predeterminado. Use --no-overwrite-ignore para abortar la operación cuando la nueva rama contiene archivos ignorados.
subm recurse-submodules no no-recurse-submodules
Usando --recurse-submodules actualizará el contenido de todos los módulos activesub de acuerdo con la confirmación registrada en el superproyecto. Si las modificaciones locales en un submódulo se sobrescriben, la comprobación fallará a menos que se use -f. Si no se utiliza nada (o --no-recurse-submodules), los árboles de trabajo de submódulos no se actualizarán.Al igual que git-submodule, esto separará HEAD del módulo sub.
overlay overlay o-overlay
En el modo de superposición predeterminado, git checkout nunca elimina archivos del índice o del árbol de trabajo. Al especificar --no-overlay, se eliminan los archivos que aparecen en el árbol de índice y trabajo, pero no en <tree-ish>, para que coincidan exactamente con <tree-ish>.
path pathspec-from-file=< file>
Pathspec se pasa en <file> en lugar de args de línea de comandos. Si<file> es exactamente -, se utiliza la entrada estándar. Los elementos de ruta están separados por LF o CR / LF. Los elementos Pathspec se pueden citar como se explica para la variable de configuración core.quotePath(consulte git-config). Véase también --pathspec-file-nul andglobal --literal-pathspecs.
path pathspec-file-nul
Solo tiene sentido con --pathspec-from-file. Los elementos Pathspec están separados con carácter NULO y todos los demás caracteres se toman literalmente (incluidas las líneas nuevas y las comillas).
<branch>
Branch to checkout; si se refiere a una rama (es decir, un nombre que,cuando se antepone con «refs/ heads/», es un ref válido), entonces esa rama se extrae. De lo contrario, si se refiere a un compromiso válido, su HEAD se convierte en «separado» y ya no está en ninguna rama (consulte más abajo para obtener más detalles).
Como caso especial, puede usar A...B como acceso directo para la base de fusión de Ay B si hay exactamente una base de fusión. Puede dejar como máximo uno de A y B, en cuyo caso el valor predeterminado es HEAD.
<new_branch>
el Nombre de la nueva sucursal.
< punto de inicio>
El nombre de un commit en el que iniciar la nueva rama; consulte la sección-rama para más detalles. El valor predeterminado es HEAD.
Como caso especial, puede usar "A...B" como acceso directo para la base de fusión de Ay B si hay exactamente una base de fusión. Puede dejar como máximo uno de A y B, en cuyo caso el valor predeterminado es HEAD.
< tree-ish>
Árbol desde el que realizar la compra (cuando se dan rutas). Si no se especifica, se utilizará el índice.
Como caso especial, puede usar "A...B" como acceso directo para la base de fusión de Ay B si hay exactamente una base de fusión. Puede dejar como máximo uno de A y B, en cuyo caso el valor predeterminado es HEAD.
not
No interprete más argumentos como opciones.
<pathspec>Limits
Limita las rutas afectadas por la operación.
Para obtener más detalles, consulte la entrada pathspec en gitglossary.