git-checkout: en línea en la nube

PROGRAMA:

NOMBRE

git-checkout: cambiar de rama o restaurar archivos de árbol de trabajo

SINOPSIS

git caja [-q] [-f] [-m] [ ]
git caja [-q] [-f] [-m] --detach [ ]
git caja [-q] [-f] [-m] [--detach]
git caja [-q] [-f] [-m] [[-b | -B | --orphan] ] [ ]
git caja [-f | --nuestros | --los suyos | -m | --conflicto = ] [] [--] ...
git caja [-p | --patch] [ ] [-] [ ...]

DESCRIPCIÓN

Actualiza archivos en el árbol de trabajo para que coincidan con la versión en el índice o el árbol especificado.
Si no se dan caminos, git caja también actualizará HEAD para establecer la rama especificada como
la rama actual.

git caja
Para prepararse para trabajar en , cámbielo actualizando el índice y los archivos
en el árbol de trabajo, y apuntando HEAD a la rama. Modificaciones locales al
Los archivos en el árbol de trabajo se guardan, de modo que puedan ser comprometidos con el .

Si no se encuentra, pero existe una rama de seguimiento en exactamente un control remoto
(llámalo ) con un nombre coincidente, tratar como equivalente a

$ git checkout -b --pista /

Podrías omitir , en cuyo caso el comando degenera para "comprobar el
rama actual ", que es un no-op glorificado con efectos secundarios bastante caros para
mostrar solo la información de seguimiento, si existe, para la rama actual.

git caja -b | -B [ ]
Especificar -b hace que se cree una nueva rama como si rama git(1) fueron llamados y
luego revisó. En este caso, puede utilizar las opciones --track o --no-track, que
será pasado a git biblioteca. Como conveniencia, --track sin -b implica rama
creación; consulte la descripción de --track a continuación.

Si se da -B, se crea si no existe; de lo contrario, se restablece.
Este es el equivalente transaccional de

$ git branch -f [ ]
$ git checkout

es decir, la rama no se reinicia / crea a menos que "git checkout" sea exitoso.

git caja --detach [ ], git caja [--despegar]
Prepárese para trabajar encima de , separando HEAD en él (ver "CABEZAL INDEPENDIENTE"
sección), y actualizar el índice y los archivos en el árbol de trabajo. Local
Las modificaciones a los archivos en el árbol de trabajo se mantienen, de modo que el trabajo resultante
El árbol será el estado registrado en la confirmación más las modificaciones locales.

Cuando el argumento es un nombre de rama, la opción --detach se puede utilizar para separar
HEAD en la punta de la rama (git checkout verificaría esa rama
sin quitar la CABEZA).

Omitiendo separa HEAD en la punta de la rama actual.

git caja [-p | --patch] [ ] [-] ...
Cuando o - se le da un parche, git caja sí No cambiar de rama. Se actualiza
las rutas nombradas en el árbol de trabajo del archivo de índice o de un nombre
(más a menudo un compromiso). En este caso, las opciones -by --track no tienen sentido y
dar cualquiera de ellos da como resultado un error. los El argumento se puede utilizar para
especificar un árbol específico (es decir, confirmación, etiqueta o árbol) para actualizar el índice de la
rutas dadas antes de actualizar el árbol de trabajo.

git caja con o --patch se usa para restaurar rutas modificadas o eliminadas a
su contenido original del índice o reemplazar las rutas con el contenido de un nombre
(la mayoría de las veces un compromiso).

El índice puede contener entradas no fusionadas debido a una combinación fallida anterior. Por defecto,
si intenta verificar una entrada de este tipo del índice, la operación de pago fallará
y no se comprobará nada. El uso de -f ignorará estas entradas no fusionadas. los
El contenido de un lado específico de la combinación se puede verificar del índice usando
- nuestro o - el de ellos. Con -m, los cambios realizados en el archivo del árbol de trabajo se pueden descartar en
vuelva a crear el resultado original de la combinación en conflicto.

OPCIONES

-q, - silencioso
Silencio, suprime los mensajes de retroalimentación.

--[sin progreso
El estado de progreso se informa en el flujo de error estándar de forma predeterminada cuando se
conectado a una terminal, a menos que se especifique --quiet. Esta bandera permite el progreso
informes incluso si no están conectados a una terminal, independientemente de --quiet.

-f, --fuerza
Al cambiar de rama, proceda incluso si el índice o el árbol de trabajo difieren de
CABEZA. Esto se usa para deshacerse de los cambios locales.

Al comprobar las rutas del índice, no falle en las entradas no fusionadas; en lugar de,
las entradas no fusionadas se ignoran.

- nuestro, - el de ellos
Al verificar las rutas del índice, consulte la etapa # 2 (soportar) o # 3 (suyo) para
caminos no fusionados.

Tenga en cuenta que durante git rebase y git pull --rebase, soportar y suyo puede aparecer intercambiado;
--our da la versión de la rama en la que se basan los cambios, mientras que --theirs
proporciona la versión de la rama que contiene su trabajo que se está modificando.

Esto se debe a que rebase se usa en un flujo de trabajo que trata el historial en el control remoto como
el canónico compartido, y trata el trabajo realizado en la rama que está rebasando como
el trabajo de terceros que se integrará, y usted está asumiendo temporalmente el papel de
el guardián de la historia canónica durante el rebase. Como guardián de lo canónico
historial, debe ver el historial desde el control remoto como nuestro (es decir, "nuestro
historia canónica "), mientras que lo que hiciste en tu rama lateral como de ellos (es decir," uno
el trabajo del colaborador encima ").

-B
Crea una nueva rama llamada y empezar en ; ver git-
biblioteca(1) para obtener más detalles.

-B
Crea la rama y empezar en ; si ya existe,
luego restablecerlo a . Esto es equivalente a ejecutar "git branch" con "-f";
ver rama git(1) para obtener más detalles.

-t, - pista
Al crear una nueva rama, establezca la configuración "ascendente". Ver "--track" en git-
biblioteca(1) para obtener más detalles.

Si no es correcto -b se da la opción, el nombre de la nueva rama se derivará de la
rama de seguimiento remoto, mirando la parte local de la especificación de referencia configurada para el
correspondiente remoto, y luego pelar la parte inicial hasta el "*". Esto sería
decirnos que usemos "hack" como la rama local cuando se ramifique de "origen / hack" (o
"remotes / origin / hack", o incluso "refs / remotes / origin / hack"). Si el nombre de pila no tiene
barra, o la adivinación anterior da como resultado un nombre vacío, la adivinación se cancela. usted
puede dar explícitamente un nombre con -b en cuyo caso.

--no hay pista
No establezca la configuración "ascendente", incluso si el branch.autoSetupMerge
La variable de configuración es verdadera.

-l
Cree el reflog de la nueva rama; ver rama git(1) para obtener más detalles.

--despegar
En lugar de revisar una sucursal para trabajar en ella, consulte una confirmación para su inspección y
experimentos descartables. Este es el comportamiento predeterminado de "git checkout " cuando
no es un nombre de sucursal. Consulte la sección "CABEZAL INDEPENDIENTE" a continuación para obtener más detalles.

--huérfano
Crear un nuevo huérfano rama, nombrada , empezó desde y cambiar
lo. La primera confirmación realizada en esta nueva rama no tendrá padres y será
la raíz de una nueva historia totalmente desconectada de todas las demás ramas y
se compromete.

El índice y el árbol de trabajo se ajustan como si hubiera ejecutado previamente "git checkout
". Esto le permite iniciar un nuevo historial que registra un conjunto de rutas
Similar a ejecutando fácilmente "git commit -a" para hacer que el root se comprometa.

Esto puede ser útil cuando desea publicar el árbol desde una confirmación sin exponer
su historia completa. 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 propietarios o
de lo contrario, bits de código gravados.

Si desea iniciar un historial desconectado que registre un conjunto de rutas que
totalmente diferente al de , entonces debería borrar el índice y
el árbol de trabajo justo después de crear la rama huérfana ejecutando "git rm -rf". de
el nivel superior del árbol de trabajo. Luego estará listo para preparar su nuevo
archivos, repoblando el árbol de trabajo, copiándolos de otro lugar, extrayendo un
bola de tarro, etc

--ignore-skip-worktree-bits
En el modo de pago disperso, git checkout - actualizaría solo las entradas que coincidan con
y patrones dispersos en $ GIT_DIR / info / sparse-checkout. Esta opción ignora la
patrones dispersos y vuelve a agregar cualquier archivo en .

-m, - fusionar
Al cambiar de rama, si tiene modificaciones locales en uno o más archivos que están
diferente entre la rama actual y la rama a la que está cambiando, el
El comando se niega a cambiar de rama para preservar sus modificaciones en contexto.
Sin embargo, con esta opción, una combinación de tres vías entre la rama actual, su trabajo
contenido del árbol, y la nueva rama está lista, y usted estará en la nueva rama.

Cuando ocurre un conflicto de fusión, las entradas de índice para las rutas en 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 resultar en la eliminación de la ruta).

Al comprobar las rutas del índice, esta opción le permite recrear el conflicto
fusionar en las rutas especificadas.

--conflict =
Lo mismo que la opción --merge anterior, pero cambia la forma en que los trozos en conflicto son
presentado, anulando la variable de configuración merge.conflictStyle. Valores posibles
son "merge" (predeterminado) y "diff3" (además de lo que se muestra con el estilo "merge",
muestra el contenido original).

-p, --parche
Seleccione de forma interactiva trozos en la diferencia entre (o el índice, si
sin especificar) y el árbol de trabajo. Los trozos elegidos se aplican luego a la inversa
árbol de trabajo (y si un se especificó, el índice).

Esto significa que puede usar git checkout -p para descartar selectivamente las ediciones de su
árbol de trabajo actual. Consulte la sección "Modo interactivo" de git-añadir(1) para aprender a
operar el modo --patch.

- ignorar-otros-árboles-de-trabajo
git checkout se niega cuando otro árbol de trabajo ya ha verificado la referencia deseada.
Esta opción hace que verifique la referencia de todos modos. En otras palabras, la referencia puede ser retenida por
más de un árbol de trabajo.


Rama para pagar; si se refiere a una rama (es decir, un nombre que, cuando se antepone con
"refs / heads /", es una referencia válida), entonces esa rama está verificada. De lo contrario, si
se refiere a una confirmación válida, su HEAD se "separa" y ya no está en ningún
rama (ver más abajo para más detalles).

Como caso especial, se comprueba la sintaxis "@ {- N}" para la última rama / confirmación N-ésima
ramas (en lugar de desprenderse). También puede especificar - cuál es sinónimo de
"@ {- 1}".

Como otro caso especial, puede utilizar "A ... B" como atajo para la base de combinación de A
y B si hay exactamente una base de fusión. Puede omitir como máximo uno de A y B, en
cuyo caso por defecto es HEAD.


Nombre de la nueva rama.


El nombre de una confirmación en la que iniciar la nueva rama; ver rama git(1) para obtener más detalles.
El valor predeterminado es HEAD.


Árbol para pagar (cuando se dan las rutas). Si no se especifica, el índice será
usado.

SEPARADO Director de escuela

HEAD normalmente se refiere a una rama con nombre (p. Ej. dominar). Mientras tanto, cada rama se refiere a un
compromiso específico. Veamos un repositorio con tres confirmaciones, una de ellas etiquetada y con
biblioteca dominar controlado:

HEAD (se refiere a la rama 'maestra')
|
v
a --- b --- c rama 'maestro' (se refiere a confirmar 'c')
^
|
etiqueta 'v2.0' (se refiere a la confirmación 'b')

Cuando se crea una confirmación en este estado, la rama se actualiza para hacer referencia a la nueva confirmación.
Específicamente, git hacer crea un nuevo compromiso d, cuyo padre está comprometido c, y entonces
sucursal de actualizaciones dominar para referirse a un nuevo compromiso d. HEAD todavía se refiere a la rama dominar y entonces
indirectamente ahora se refiere a comprometerse d:

$ editar; git add; git commit

HEAD (se refiere a la rama 'maestra')
|
v
a --- b --- c --- d rama 'maestro' (se refiere a confirmar 'd')
^
|
etiqueta 'v2.0' (se refiere a la confirmación 'b')

A veces es útil poder verificar una confirmación que no está en la punta de ningún nombre
rama, o incluso para crear una nueva confirmación a la que no hace referencia una rama con nombre. Vamos
mira lo que sucede cuando nos comprometemos a pagar b (aquí mostramos dos formas de hacerlo):

$ git checkout v2.0 # o
$ git checkout master ^^

HEAD (se refiere a cometer 'b')
|
v
a --- b --- c --- d rama 'maestro' (se refiere a confirmar 'd')
^
|
etiqueta 'v2.0' (se refiere a la confirmación 'b')

Tenga en cuenta que independientemente del comando de pago que usemos, HEAD ahora se refiere directamente a
hacer b. Esto se conoce como estado HEAD separado. Significa simplemente que HEAD se refiere
a una confirmación específica, en lugar de hacer referencia a una rama con nombre. Veamos qué pasa
cuando creamos un compromiso:

$ editar; git add; git commit

HEAD (se refiere a cometer 'e')
|
v
e
/
a --- b --- c --- d rama 'maestro' (se refiere a confirmar 'd')
^
|
etiqueta 'v2.0' (se refiere a la confirmación 'b')

Ahora hay un nuevo compromiso e, pero solo se hace referencia en HEAD. Por supuesto, podemos agregar todavía
otro compromiso en este estado:

$ editar; git add; git commit

HEAD (se refiere a cometer 'f')
|
v
e --- f
/
a --- b --- c --- d rama 'maestro' (se refiere a confirmar 'd')
^
|
etiqueta 'v2.0' (se refiere a la confirmación 'b')

De hecho, podemos realizar todas las operaciones normales de Git. Pero, veamos lo que pasa
cuando luego realizamos el pago maestro:

$ git pago maestro

HEAD (se refiere a la rama 'maestra')
e --- f |
/ v
a --- b --- c --- d rama 'maestro' (se refiere a confirmar 'd')
^
|
etiqueta 'v2.0' (se refiere a la confirmación 'b')

Es importante darse cuenta de que en este punto nada se refiere a cometer f. Finalmente
hacer f (y por extensión confirmar e) será eliminado por la recolección de basura rutinaria de Git
proceso, a menos que creemos una referencia antes de que eso suceda. Si aún no nos hemos alejado
de cometer f, cualquiera de estos creará una referencia a él:

$ git pago -b foo (1)
$ git rama foo (2)
$ git etiqueta foo (3)

1. crea una nueva rama foo, que se refiere a cometer f, y luego actualiza HEAD para referirse a
biblioteca foo. En otras palabras, ya no estaremos en estado HEAD separado después de este comando.
2. crea de manera similar una nueva rama foo, que se refiere a cometer f, pero deja HEAD desprendida.
3. crea una nueva etiqueta foo, que se refiere a cometer f, dejando HEAD separada.

Si nos hemos alejado del compromiso f, primero debemos recuperar su nombre de objeto (normalmente
usando git reflog), y luego podemos crear una referencia a él. Por ejemplo, para ver el
Las últimas dos confirmaciones a las que se refirió HEAD, podemos usar cualquiera de estos comandos:

$ git reflog -2 HEAD # o
$ git registro -g -2 CABEZA

EJEMPLOS

1. La siguiente secuencia comprueba la rama maestra, revierte el Makefile a dos
revisiones, elimina hello.c por error y lo recupera del índice.

$ git pago maestro (1)
$ git checkout master ~ 2 Makefile (2)
$ rm -f hola.c
$ git pago hola.c (3)

1. cambiar de rama
2. sacar un archivo de otra confirmación
3. restaurar hello.c desde el índice

Si quieres echa un vistazo que todas C archivos fuente fuera del índice, puede decir

$ git checkout - '* .c'

Tenga en cuenta las comillas alrededor de * .c. El archivo hello.c también se desprotegerá, aunque
ya no está en el árbol de trabajo, porque el archivo globbing se usa para hacer coincidir las entradas
en el índice (no en el árbol de trabajo por el shell).

Si tiene una rama desafortunada que se llama hello.c, este paso sería confuso
como una instrucción para cambiar a esa rama. En su lugar, debería escribir:

$ git checkout - hello.c

2. Después de trabajar en la rama incorrecta, se cambiaría a la rama correcta.
mediante:

$ git checkout mi tema

Sin embargo, su rama "incorrecta" y su rama "mytopic" correcta pueden diferir en los archivos que
se han modificado localmente, en cuyo caso el pago anterior fallaría así:

$ git checkout mi tema
error: tiene cambios locales en 'frotz'; no cambiar de sucursal.

Puede darle el indicador -m al comando, que intentaría una combinación de tres vías:

$ git checkout -m mi tema
Frotz de fusión automática

Después de esta fusión de tres vías, las modificaciones locales son No registrado en su índice
archivo, por lo que git diff le mostrará los cambios que realizó desde la sugerencia de la nueva
.

3. Cuando ocurre un conflicto de fusión durante el cambio de rama con la opción -m, debería
ver algo como esto:

$ git checkout -m mi tema
Frotz de fusión automática
ERROR: Fusionar conflicto en frotz
fatal: el programa de fusión falló

En este punto, git diff muestra los cambios fusionados limpiamente como en el ejemplo anterior,
así como los cambios en los archivos en conflicto. Edite y resuelva el conflicto y marque
se resolvió con git add como de costumbre:

$ editar frotz
$ git agregar frotz

GIT

Parte de los git(1) suite

Use git-checkout en línea usando los servicios de onworks.net