git-commit: en línea en la nube

PROGRAMA:

NOMBRE

git-commit: registra los cambios en el repositorio

SINOPSIS

git hacer [-a | --interactivo | --parche] [-s] [-v] [-u ] [--enmendar]
[--secar-ejecutar] [(-c | -C | --fixup | --squash) ]
[-F | -metro ] [--reset-author] [--allow-empty]
[--permitir-mensaje-vacío] [--no-verificar] [-e] [--author = ]
[--fecha = ] [--cleanup = ] [--[sin Estado]
[-i | -o] [-S [ ]] [-] [ ...]

DESCRIPCIÓN

Almacena el contenido actual del índice en una nueva confirmación junto con un mensaje de registro del
usuario describiendo los cambios.

El contenido que se agregará se puede especificar de varias maneras:

1. usando git add para "agregar" cambios al índice de forma incremental antes de usar el hacer
comando (Nota: incluso los archivos modificados deben ser "agregados");

2. usando git rm para eliminar archivos del árbol de trabajo y el índice, nuevamente antes
usando el hacer mando;

3. enumerando archivos como argumentos a la hacer comando, en cuyo caso la confirmación
ignorar los cambios realizados en el índice y, en su lugar, registrar el contenido actual del
archivos listados (que Git ya debe conocer);

4. mediante el uso del modificador -a con el hacer comando para "agregar" automáticamente los cambios de todos
archivos conocidos (es decir, todos los archivos que ya están listados en el índice) y automáticamente
archivos "rm" en el índice que se han eliminado del árbol de trabajo y, a continuación, realice
el compromiso real;

5. mediante el uso de los interruptores --interactive o --patch con el hacer comando para decidir uno
por uno qué archivos o trozos deben ser parte de la confirmación, antes de finalizar el
operación. Consulte la sección "Modo interactivo" de git-añadir(1) para aprender a operar
estos modos.

La opción --dry-run se puede utilizar para obtener un resumen de lo que incluye cualquiera de los
arriba para la próxima confirmación dando el mismo conjunto de parámetros (opciones y rutas).

Si realiza una confirmación y luego encuentra un error inmediatamente después de eso, puede recuperarse de
con git reajustar.

CAMPUS

-a, --todos
Indique al comando que organice automáticamente los archivos que se han modificado y eliminado, pero
los archivos nuevos que no le hayas informado a Git no se verán afectados.

-p, --parche
Utilice la interfaz de selección de parches interactiva para elegir qué cambios confirmar. Ver
git-añadir(1) para obtener más detalles.

-C , --reuse-message =
Tome un objeto de confirmación existente y reutilice el mensaje de registro y la autoría
información (incluida la marca de tiempo) al crear la confirmación.

-C , --reedit-message =
Me gusta -C, pero con -c se invoca el editor, para que el usuario pueda editar más el
cometer mensaje.

--fixup =
Construya un mensaje de confirmación para usar con rebase --autosquash. El mensaje de confirmación
sea ​​la línea de asunto de la confirmación especificada con el prefijo "fixup!". Ver git-
rebase(1) para obtener más detalles.

--squash =
Construya un mensaje de confirmación para usar con rebase --autosquash. El mensaje de confirmación
La línea de asunto se toma de la confirmación especificada con el prefijo "squash!". Puede ser
se utiliza con opciones de mensaje de confirmación adicionales (-m / -c / -C / -F). Ver git-rebase(1) para
Detalles.

--reset-autor
Cuando se usa con -C / -c / - modificar opciones, o cuando se confirma después de un conflicto
cherry-pick, declara que la autoría de la confirmación resultante ahora pertenece al
cometer. Esto también renueva la marca de tiempo del autor.

--pequeño
Cuando realice un ensayo, proporcione el resultado en formato corto. Ver estado-git(1) para
detalles. Implica: ejecución en seco.

--rama
Muestre la información de la sucursal y el seguimiento incluso en formato corto.

--porcelana
Cuando realice una ejecución en seco, proporcione la salida en un formato listo para porcelana. Ver estado-git(1)
para detalles. Implica: ejecución en seco.

--largo
Cuando realice una ejecución en seco, proporcione la salida en formato largo. Implica: ejecución en seco.

-z, --nulo
Cuando se muestra una salida de estado corta o de porcelana, finalice las entradas en la salida de estado
con NUL, en lugar de LF. Si no se proporciona ningún formato, implica el formato de salida --porcelain.

-F , --archivo =
Toma el mensaje de confirmación del archivo dado. Usar - para leer el mensaje del
entrada estándar.

--author =
Anula el autor de la confirmación. Especifique un autor explícito utilizando el estándar AU Thor
<[email protected]> formato. De lo contrario se supone que es un patrón y se utiliza
para buscar una confirmación existente por ese autor (es decir, rev-list --all -i
--author = ); el autor de la confirmación se copia de la primera confirmación de este tipo que se encuentra.

--fecha =
Anula la fecha del autor utilizada en la confirmación.

-metro , --mensaje =
Usa lo dado como el mensaje de confirmación. Si se dan varias opciones -m, su
los valores se concatenan como párrafos separados.

-t , --template =
Al editar el mensaje de confirmación, inicie el editor con el contenido del archivo dado.
La variable de configuración commit.template se usa a menudo para dar esta opción
implícitamente al comando. Este mecanismo puede ser utilizado por proyectos que quieran orientar
participantes con algunas sugerencias sobre qué escribir en el mensaje y en qué orden. Si el
el usuario sale del editor sin editar el mensaje, la confirmación se cancela. Esto no tiene
efecto cuando un mensaje se da por otros medios, por ejemplo, con las opciones -m o -F.

-s, --firmar
Agregue la línea Signed-off-by por el confirmador al final del mensaje de registro de confirmación. los
El significado de una firma depende del proyecto, pero normalmente certifica que el
tiene los derechos para enviar este trabajo bajo la misma licencia y está de acuerdo con un Desarrollador
Certificado de origen (ver http://developercertificate.org/ ).

-n, --no-verificar
Esta opción omite los ganchos pre-commit y commit-msg. Ver también garfios(5).

--permitido-vacío
Por lo general, grabar una confirmación que tiene exactamente el mismo árbol que la confirmación principal única es una
error, y el comando le impide realizar tal compromiso. Esta opción omite
seguridad, y es principalmente para su uso por scripts de interfaz SCM externos.

--permitir-mensaje-vacío
Como --allow-empty, este comando es principalmente para ser utilizado por scripts de interfaz SCM externos.
Le permite crear una confirmación con un mensaje de confirmación vacío sin usar plomería
comandos como git-commit-árbol(1).

--cleanup =
Esta opción determina cómo se debe limpiar el mensaje de confirmación proporcionado antes
comprometerse. los puede ser tira, espacio en blanco, palabra por palabra, tijeras o por defecto.

tira
Elimine las líneas vacías iniciales y finales, los espacios en blanco finales, los comentarios y
colapsar líneas vacías consecutivas.

espacio en blanco
Igual que la tira, excepto que no se elimina el comentario.

literal
No cambie el mensaje en absoluto.

tijeras
Igual que los espacios en blanco, excepto que todo desde (e incluida) la línea "#
------------------------> 8 ------------------------ "se trunca si el mensaje
se va a editar. "#" se puede personalizar con core.commentChar.

tu préstamo estudiantil
Igual que strip si el mensaje se va a editar. De lo contrario, espacios en blanco.

El valor predeterminado puede ser cambiado por el cometer.limpieza variable de configuración (ver git-
config(1)).

-e, --edit
El mensaje tomado del archivo con -F, línea de comando con -m, y del objeto de confirmación con
-C se utilizan normalmente como mensaje de registro de confirmación sin modificar. Esta opción le permite más
edite el mensaje tomado de estas fuentes.

--sin editar
Utilice el mensaje de confirmación seleccionado sin iniciar un editor. Por ejemplo, git commit
--amend --no-edit corrige una confirmación sin cambiar su mensaje de confirmación.

--enmendar
Reemplaza la punta de la rama actual creando una nueva confirmación. El árbol registrado es
preparado como de costumbre (incluido el efecto de las opciones -i y -o y explícito
pathpec), y el mensaje de la confirmación original se utiliza como punto de partida,
en lugar de un mensaje vacío, cuando no se especifica ningún otro mensaje desde la línea de comando
a través de opciones como -m, -F, -c, etc. La nueva confirmación tiene los mismos padres y autor que
el actual (la opción --reset-author puede contrarrestar esto).

Es un equivalente aproximado de:

$ git reset --soft HEAD ^
$ ... haz algo más para encontrar el árbol correcto ...
$ git confirmar -c ORIG_HEAD

pero se puede utilizar para modificar un compromiso de fusión.

Debe comprender las implicaciones de reescribir el historial si modifica una confirmación que
ya ha sido publicado. (Consulte la sección "RECUPERACIÓN DEL RECUPERACIÓN ARRIBA" en git-
rebase(1).)

--no-post-reescribir
Omita el gancho posterior a la reescritura.

-Incluyo
Antes de realizar una confirmación a partir de los contenidos organizados hasta ahora, organice el contenido de las rutas
dado en la línea de comando también. Por lo general, esto no es lo que desea a menos que esté
concluyendo una fusión conflictiva.

-o, - solo
Realice una confirmación tomando el contenido del árbol de trabajo actualizado de las rutas especificadas en
la línea de comando, sin tener en cuenta cualquier contenido que se haya preparado para otras rutas.
Este es el modo de funcionamiento predeterminado de git hacer si se dan caminos en el
línea de comando, en cuyo caso esta opción se puede omitir. Si se especifica esta opción
Junto con --enmendar, entonces no es necesario especificar rutas, que se pueden utilizar para modificar
la última confirmación sin realizar cambios que ya se han realizado.

-u [ ], - archivos sin seguimiento [= ]
Muestra archivos sin seguimiento.

El parámetro de modo es opcional (por defecto es todos), y se utiliza para especificar el manejo
de archivos sin seguimiento; cuando no se utiliza -u, el valor predeterminado es normal, es decir, mostrar sin seguimiento
archivos y directorios.

Las posibles opciones son:

· no - No mostrar archivos sin seguimiento

· normal - Muestra archivos y directorios sin seguimiento

· todos - También muestra archivos individuales en directorios sin seguimiento.

El valor predeterminado se puede cambiar usando la configuración status.showUntrackedFiles
variable documentada en git-config(1).

-v, --detallado
Muestre una diferencia unificada entre la confirmación HEAD y lo que se confirmaría en la parte inferior de
la plantilla de mensaje de confirmación para ayudar al usuario a describir la confirmación recordando qué
cambios que tiene la confirmación. Tenga en cuenta que esta salida de diferencia no tiene sus líneas prefijadas
#. Esta diferencia no será parte del mensaje de confirmación.

Si se especifica dos veces, muestre además la diferencia unificada entre lo que se comprometería
y los archivos del árbol de trabajo, es decir, los cambios sin etapas en los archivos rastreados.

-q, - silencioso
Suprime el mensaje de resumen de confirmación.

- corrida en seco
No cree una confirmación, pero muestre una lista de rutas que deben confirmarse, rutas con
cambios locales que se dejarán sin confirmar y rutas sin seguimiento.

--estado
Incluya la salida de estado-git(1) en la plantilla de mensaje de confirmación cuando se utiliza un
editor para preparar el mensaje de confirmación. Está activado de forma predeterminada, pero se puede utilizar para anular
variable de configuración commit.status.

--sin Estado
No incluya la salida de estado-git(1) en la plantilla de mensaje de confirmación al usar
un editor para preparar el mensaje de confirmación predeterminado.

-S[ ], --gpg-sign [= ]
GPG-sign confirma. El argumento keyid es opcional y el valor predeterminado es el confirmador.
identidad; si se especifica, debe pegarse a la opción sin un espacio.

--no-gpg-signo
Countermand commit.gpg Variable de configuración de firma que está configurada para forzar todas y cada una
comprometerse a ser firmado.

--
No interprete más argumentos como opciones.

...
Cuando se dan archivos en la línea de comando, el comando confirma el contenido del
archivos con nombre, sin registrar los cambios ya realizados. El contenido de estos archivos
también se preparan para el próximo compromiso además de lo que se ha preparado antes.

FECHA FORMATOS

Las variables de entorno GIT_AUTHOR_DATE, GIT_COMMITTER_DATE y la opción --date
admite los siguientes formatos de fecha:

Formato interno de Git
Está , dónde es el numero de
segundos desde la época de UNIX. es una compensación positiva o negativa
desde UTC. Por ejemplo, CET (que está 2 horas por delante de UTC) es +0200.

RFC 2822
El formato de correo electrónico estándar como se describe en RFC 2822, por ejemplo, jueves, 07 de abril de 2005
22:13:13 +0200.

ISO 8601
Hora y fecha especificadas por la norma ISO 8601, por ejemplo 2005-04-07T22: 13: 13. los
El analizador también acepta un espacio en lugar del carácter T.

Note
Además, la parte de la fecha se acepta en los siguientes formatos: AAAA.MM.DD,
MM / DD / AAAA y DD.MM.YYYY.

EJEMPLOS

Al grabar su propio trabajo, el contenido de los archivos modificados en su árbol de trabajo se
almacenado temporalmente en un área de preparación llamada "índice" con git add. Un archivo puede ser
revirtió, solo en el índice pero no en el árbol de trabajo, al de la última confirmación
con git reset HEAD - , que revierte efectivamente git add y previene los cambios
a este archivo de participar en la próxima confirmación. Después de construir el estado para ser
confirmado de forma incremental con estos comandos, git commit (sin ningún parámetro de nombre de ruta)
se utiliza para registrar lo que se ha escenificado hasta ahora. Esta es la forma más básica del comando.
Un ejemplo:

$ editar hola.c
$ git rm adiós.c
$ git agregar hola.c
$ git confirmar

En lugar de almacenar archivos después de cada cambio individual, puede decirle a git commit que lo notifique
los cambios en los archivos cuyo contenido se rastrea en su árbol de trabajo y
correspondiente git add y git rm para usted. Es decir, este ejemplo hace lo mismo que el
ejemplo anterior si no hay ningún otro cambio en su árbol de trabajo:

$ editar hola.c
$ rm adiós.c
$ git confirmar -a

El comando git commit -a primero mira su árbol de trabajo, nota que ha modificado
hello.cy eliminó goodbye.c, y realiza git add y git rm necesarios para usted.

Después de realizar cambios en muchos archivos, puede modificar el orden en el que se registran los cambios,
dando nombres de ruta a git commit. Cuando se dan los nombres de ruta, el comando realiza una confirmación
que solo registra los cambios realizados en las rutas nombradas:

$ editar hola.c hola.h
$ git agregar hola.c hola.h
$ editar Makefile
$ git confirmar Makefile

Esto hace una confirmación que registra la modificación en Makefile. Los cambios organizados para
hello.cy hello.h no se incluyen en la confirmación resultante. Sin embargo, sus cambios son
no se pierden, todavía se organizan y simplemente se retienen. Después de la secuencia anterior, si
hacer:

$ git confirmar

esta segunda confirmación registraría los cambios a hello.cy hello.h como se esperaba.

Después de una fusión (iniciada por git unir or git recogida ) se detiene debido a conflictos, limpiamente
Las rutas fusionadas ya están preparadas para ser comprometidas para usted, y las rutas que entraron en conflicto son
dejado en estado no fusionado. Primero tendría que verificar qué rutas están en conflicto con git
estado y después de arreglarlos manualmente en su árbol de trabajo, organizaría el resultado como
habitual con git add:

$ git status | grep no fusionado
no fusionado: hola.c
$ editar hola.c
$ git agregar hola.c

Después de resolver conflictos y preparar el resultado, git ls-files -u dejaría de mencionar
el camino conflictivo. Cuando haya terminado, ejecute git commit para finalmente registrar la fusión:

$ git confirmar

Al igual que en el caso de registrar sus propios cambios, puede usar la opción -a para guardar la escritura. Uno
La diferencia es que durante una resolución de fusión, no puede usar git commit con nombres de ruta para
alterar el orden en que se confirman los cambios, porque la fusión debe registrarse como un
compromiso único. De hecho, el comando se niega a ejecutarse cuando se le dan nombres de ruta (pero vea -i
opción).

DISCUSIÓN

Aunque no es obligatorio, es una buena idea comenzar el mensaje de confirmación con un solo mensaje corto.
(menos de 50 caracteres) línea que resume el cambio, seguida de una línea en blanco y luego una
descripción más completa. El texto hasta la primera línea en blanco en un mensaje de confirmación es
tratado como el título de confirmación, y ese título se usa en todo Git. Por ejemplo, git-
parche de formato(1) convierte una confirmación en correo electrónico y usa el título en la línea Asunto y
el resto del compromiso en el cuerpo.

Git es hasta cierto punto independiente de la codificación de caracteres.

· El contenido de los objetos blob son secuencias de bytes no interpretadas. No hay
codificación de la traducción a nivel básico.

· Los nombres de las rutas están codificados en la forma C de normalización UTF-8. Esto se aplica a los objetos de árbol,
el archivo de índice, los nombres de las referencias, así como los nombres de las rutas en los argumentos de la línea de comandos,
variables de entorno y archivos de configuración (.git / config (ver git-config(1)), ignorar(5)
atributos de git(5) y módulos de git(5)).

Tenga en cuenta que Git en el nivel central trata los nombres de ruta simplemente como secuencias de no NUL
bytes, no hay conversiones de codificación de nombre de ruta (excepto en Mac y Windows).
Por lo tanto, el uso de nombres de ruta que no sean ASCII funcionará principalmente incluso en plataformas y archivos
sistemas que utilizan codificaciones ASCII extendidas heredadas. Sin embargo, los repositorios creados en
dichos sistemas no funcionarán correctamente en sistemas basados ​​en UTF-8 (por ejemplo, Linux, Mac, Windows)
y viceversa. Además, muchas herramientas basadas en Git simplemente asumen que los nombres de ruta son
UTF-8 y no mostrará correctamente otras codificaciones.

· Los mensajes de registro de confirmación generalmente se codifican en UTF-8, pero otras codificaciones ASCII extendidas
también son compatibles. Esto incluye ISO-8859-x, CP125x y muchos otros, pero no
Codificaciones multibyte UTF-16/32, EBCDIC y CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc.).

Aunque recomendamos que los mensajes de registro de confirmación estén codificados en UTF-8, tanto el núcleo como el
Git Porcelain está diseñado para no forzar UTF-8 en proyectos. Si todos los participantes de un
proyecto particular les resulta más conveniente utilizar codificaciones heredadas, Git no prohíbe
eso. Sin embargo, hay algunas cosas a tener en cuenta.

1. git hacer y git árbol de compromiso emite una advertencia si el mensaje de registro de confirmación que se le da
no parece una cadena UTF-8 válida, a menos que diga explícitamente que su proyecto usa una
codificación heredada. La forma de decir esto es tener i18n.commitencoding en .git / config
archivo, así:

[i18n]
codificación de compromiso = ISO-8859-1

Los objetos de confirmación creados con la configuración anterior registran el valor de i18n.commitencoding
en su encabezado de codificación. Esto es para ayudar a otras personas que los vean más tarde. Falta de
este encabezado implica que el mensaje de registro de confirmación está codificado en UTF-8.

2. git log, git Mostrar, git culpa y los amigos miran el encabezado de codificación de una confirmación
e intente volver a codificar el mensaje de registro en UTF-8 a menos que se especifique lo contrario. usted
puede especificar la codificación de salida deseada con i18n.logoutputencoding en .git / config
archivo, así:

[i18n]
codificación de salida de sesión = ISO-8859-1

Si no tiene esta variable de configuración, el valor de i18n.commitencoding es
utilizado en su lugar.

Tenga en cuenta que elegimos deliberadamente no volver a codificar el mensaje de registro de confirmación cuando se realiza una confirmación.
hecho para forzar UTF-8 en el nivel de objeto de confirmación, porque la recodificación a UTF-8 no es
necesariamente una operación reversible.

MEDIO AMBIENTE Y CONFIGURACIÓN VARIABLES

El editor utilizado para editar el mensaje de registro de confirmación se elegirá de GIT_EDITOR
variable de entorno, la variable de configuración core.editor, el entorno VISUAL
variable, o la variable de entorno EDITOR (en ese orden). Ver git-var(1) para obtener más detalles.

MANOS

Este comando puede ejecutar ganchos commit-msg, prepare-commit-msg, pre-commit y post-commit.
See garfios(5) para obtener más información.

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