Español ▾ Topics ▾ Latest version ▾ git-commit last updated in 2.50.0

NOMBRE

git-commit - Registra cambios en el repositorio

SINOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<modo>]] [--amend] [--dry-run] [(-c | -C | --squash) <confirmación> | --fixup [(amend|reword):]<confirmación>] [-F <fichero> | -m <mensaje>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<autor>] [--date=<fecha>] [--cleanup=<modo>] [--[no-]status] [-i | -o] [--pathspec-from-file=<fichero> [--pathspec-file-nul]] [(--trailer <token>[(=|:)<valor>])…​] [-S[<id-clave>]] [--] [<especificación-de-ruta>…​]

DESCRIPCIÓN

Crea una nueva confirmación con el contenido actual del índice y el mensaje de bitácora dado que describe los cambios. La nueva confirmación es un hijo directo de HEAD, usualmente la punta de la rama actual, y la rama es actualizada para apuntar a ella (a menos que no haya una rama asociada con el árbol de trabajo, en cuyo caso HEAD se "desprende" como se describe git-checkout[1]).

El contenido a ser confirmado puede especificarse de varias maneras:

  1. usando git-add[1] para "agregar" incrementalmente cambios al índice antes de usar el comando commit (Nota: incluso ficheros modificados deben ser "agregados");

  2. usando git-rm[1] para remover ficheros del árbol de trabajo y el índice, también antes de usar el comando commit;

  3. listando ficheros como argumentos al comando commit (sin alguna de las opciones --interactive o --patch), en cuyo caso la confirmación ignorará cambios presentados en el índice, y en su lugar registrará el contenido actual de la lista de ficheros (la cual ya debe ser del conocimiento de Git);

  4. usando el modificador -a con el comando commit para "agregar" automáticamente cambios de todos los ficheros conocidos (ej. todos los ficheros que ya están listados en el índice) y "remover" automáticamente los ficheros en el índice quitados del árbol de trabajo, y entonces realizar la confirmación actual;

  5. usando los modificadores --interactive o --patch con el comando commit para decidir uno por uno cuáles ficheros o pedazos deberán ser parte de la confirmación además del contenido en el índice, antes de finalizar la operación. Ver la sección ``Modo Interactivo" de git-add[1] para aprender cómo operar esos modos.

La opción --dry-run puede usarse para obtener un resumen de lo que se incluirá en cualquiera de los anteriores para la confirmación siguiente dando el mismo conjunto de parámetros (opciones y rutas).

Si haces una confirmación y luego encuentras un error inmediatamente después, puedes recuperarte de él con git reset.

OPCIONES

-a
--all

Presenta automáticamente los ficheros que han sido modificados y eliminados, pero los ficheros nuevos que no le has enterado a Git no son afectados.

-p
--patch

Usa la interfase de selección de parche interactiva para elegir cuáles cambios se confirmarán. Ver git-add[1] para detalles.

-C <confirmación>
--reuse-message=<confirmación>

Toma un objeto <confirmación> existente, y reusa el mensaje de registro y la información de autoría (incluyendo la marca de tiempo) cuando se crea la confirmación.

-c <confirmación>
--reedit-message=<confirmación>

Como -C, pero con -c se invoca al editor, de tal manera que el usuario pueda editar posteriormente el mensaje de confirmación.

--fixup=[(amend|reword):]<confirmación>

Crea una nueva confirmación que "arregla" <confirmación> cuando se aplica con git rebase --autosquash. Un --fixup=<confirmación> de plano crea una confirmación "arreglo" que modifica el contenido de <commit> pero sin tocar su mensaje de registro. --fixup=amend:<confirmación> es similar pero crea una confirmación "enmieda" la cual además reemplaza el mensaje de registro de <confirmación> con el mensaje de la confirmación "enmienda". --fixup=reword:<confirmación> crea una confirmación "enmienda" que reemplaza el mensaje de registro de <confirmación> con su propio mensaje pero sin hacer cambios al contenido de <confirmación>.

La confirmación creada por --fixup=<confirmación>`plano tiene un título compuesto de "fixup!" seguido por el título de _<confirmación>_, y es reconocido especialmente por `git rebase --autosquash. La opción -m puede usarse para suplir el mensaje de la confirmación creada, pero el comentario adicional será tirado una vez que la confirmación "arreglo" aplaste <confirmación> por git rebase --autosquash.

La confirmación creada por --fixup=amend:<confirmación> es similar pero su título es prefijado con "amend!". El mensaje de <confirmación> es copiado en el mensaje de registro de la confirmación "amend!" y se abre en un editor para que se pueda refinar. Cuando git rebase --autosquash aplasta la confirmación "amend!" en <confirmación>, el mensaje de <confirmación> es reemplazado por el mensaje de registro refinado de la confirmación "amend!". Es un error para el mensaje de registro de la confirmación "amend!" que esté vacío a menos que se especifique --allow-empty-message.

--fixup=reword:<confirmación> es un atajo de --fixup=amend:<confirmación> --only. Crea una confirmación "amend!" con sólo un mensaje de registro (ignorando cualquier cambio presentado al índice). Cuando es aplastado por git rebase --autosquash, reemplaza el mensaje de registro de <confirmación> sin hacer algún otro cambio.

Ninguna de las confirmaciones "fixup!" o "amend!" cambia la autoría de <confirmación> cuando es aplicado por git rebase --autosquash. Ver git-rebase[1] para detalles.

--squash=<confirmación>

Construye un mensaje de confirmación para usarse con git rebase --autosquash. El título del mensaje de confirmación se toma de la confirmación especificada con un prefijo "squash!". Puede usarse con opciones adicionales de mensaje de confirmación (-m/-c/-C/-F). Ver git-rebase[1] para detalles.

--reset-author

Cuando se usa con las opciones -C/-c/--amend, o cuando se confirma después de una cherry-pick conflictiva, declara que la autoría de la confirmación resultante ahora pertenece al confirmante. Esto también renueva la marca de tiempo del autor.

--short

Cuando se corre en seco, da la salida en formato corto. Ver git-status[1] para detalles. Implica --dry-run.

--branch

Muestra la rama y la información de rastreo también en formato corto.

--porcelain

Cuando se corre en seco, da la salida en un formato para porcelana. Ver git-status[1] para detalles. Implica --dry-run.

--long

Cuando se corre en seco, da la salida en el formato largo. Implica --dry-run.

-z
--null

Cuando se muestra el estatus de salida short o porcelain, imprime el nombre del fichero verbosamente y termina las entradas con NUL, en lugar de con LF. Si no se da un formato, implica el formato de salida --porcelain. Sin la opción -z, los nombre de fichero con caracteres "inusuales" son entrecomillados como se explica para la variable de configuración core.quotePath (ver git-config[1]).

-F <fichero>
--file=<fichero>

Toma el mensaje de confirmación de <fichero>. Use - para leer el mensaje de la entrada estándar.

--author=<autor>

Anula el autor de la confirmación. Especifica un autor explícito usando el formato estándar A U Tor <autor@ejemplo.com>. De lo contrario se asume <autor> como un patrón y se usa para buscar una confirmación existente por ese autor (ej. git rev-list --all -i --author=<autor>); el autor de la confirmación es copiado de la primer confirmación encontrada.

--date=<fecha>

Anula la fecha de autoría usada en la confirmación.

-m <mensaje>
--message=<mensaje>

Usa <mensaje> como mensaje de confirmación. Si se dan múltiples opciones -m, sus valores son concatenados como párrafos separados.

La opción -m es mutuamente excluyente con -c, -C, y -F.

-t <fichero>
--template=<fichero>

Al editar el mensaje de confirmación, inicia el editor con el contenido de <fichero>. Se usa a menudo la variable de configuración commit.template para dar implícitamente esta opción al comando. Este mecanismo puede ser usado por proyectos que quieran guiar a los participantes con algunas sugerencias sobre qué escribir en el mensaje y en qué orden. Si el usuario sale del editor sin editar el mensaje, se aborta la confirmación. Esto no surte efecto cuando el mensaje se proporciona por otros medios, ej. con las opciones -m o -F.

Warning

Missing es/signoff-option.adoc

See original version for this content.
--trailer <token>[(=|:)<valor>]

Especifica un par (<token>, <valor>) que será aplicado como colofón. (ej. git commit --trailer "Firmado-por:C O Mitter \ <confirmante@ejemplo.com>" --trailer "Ayudado-por:C O Mitter \ <confirmante@ejemplo.com>" agregará los remolques Firmado-por y Ayudado-por al mensaje de confirmación). Se pueden usar las variables de configuración trailer.*(git-interpret-trailers[1]) para definir si un colofón duplicado se omite, si debe aparecer cada colofón al correr los colofones, y otros detalles.

-n
--[no-]verify

Evita los ganchos pre-commit y commit-msg. Ver también githooks[5].

--allow-empty

Usualmente registrar una confirmación que tenga exactamente el mismo árbol como su único antecesor es un error, y el comando te previene de hacer tal confirmación. Esta opción omite la seguridad, y es primordialmente para ser usada por scripts de interfase de SCM foráneos.

--allow-empty-message

Crea una confirmación con un mensaje de confirmación vacío sin usar comandos plomería como git-commit-tree[1]. Como --allow-empty, este comando es primordialmente para ser usado por scripts de interface de SCM externos.

--cleanup=<modo>

Determina cómo debería ser limpiado el mensaje de confirmación proporcionado antes confirmar. El <modo> puede ser strip, whitespace, verbatim, scissors o default.

strip

Quita líneas vacías iniciales y finales, espacios en blanco al final, comentarios y colapsa líneas vacías consecutivas.

whitespace

Lo mismo que strip excepto que #comentario no se quita.

verbatim

No cambia el mensaje en absoluto.

scissors

Lo mismo que whitespace excepto que todo desde (incluyendo) la línea encontrada abajo es truncada, si el mensaje va a editarse. "#" puede personalizarse con core.commentChar.

# ------------------------ >8 ------------------------
default

Lo mismo que strip si el mensaje va a editarse. De lo contrario whitespace.

El predeterminado puede cambiarse con la variable de configuración commit.cleanup (ver git-config[1]).

-e
--edit

Permite al usuario editar más adelante el mensaje tomado de <fichero> con -F <fichero>, de la línea de comando con -m <mensaje>, y de <confirmación> con `-C <confirmación>.

--no-edit

Usa el mensaje de confirmación seleccionado sin lanzar un editor. Por ejemplo, git commit --amend --no-edit enmienda una confirmación sin cambiar su mensaje de confirmación.

--amend

Reemplaza la punta de la rama actual creando una nueva confirmación. El árbol registrado se prepara como siempre (incluyendo el efecto de las opciones -i y -o y especificaciones de ruta explícitas), y el mensaje de la confirmación original se usa como el punto inicial, en lugar de un mensaje vacío, cuando no se especifica otro mensaje desde la línea de comandos mediante opciones como -m, -F, -c, etc. La nueva confirmación tiene los mismos antecesores y autor que la actual (la opción --reset-author puede contraordenar esto).

Es un equivalente burdo de:

	$ git reset --soft HEAD^
	$ ... hace algo mas que llegará con el árbol correcto ...
	$ git commit -c ORIG_HEAD

pero puede ser usado para enmendar una confirmación de fusión.

Deberías entender las implicaciones de reescribir el historial si enmiendas una confirmación que ya ha sido publicada. (ver la sección "RECUPERANDOSE DE UN REBASE DE UPSTREAM" en git-rebase[1].)

--no-post-rewrite

Evita el gancho post-rewrite.

-i
--include

Antes de hacer una confirmación con el contenido presentado al momento, presenta también el contenido de las rutas proporcionadas en la línea de comandos. Esto no es normalmente lo que quieres, a menos que estes concluyendo una fusión con conflictos.

-o
--only

Crea una confirmación tomando el contenido actualizado del árbol de trabajo de las rutas especificadas en la línea de comandos, descartando cualquier contenido que haya sido presentado por otras rutas. Este es el modo de operación predeterminado de git commit si se da alguna ruta en la línea de comandos, en cuyo caso esta opción puede omitirse. Si esta opción se especifica junto con --amend, entonces no hay necesidad de especificar rutas que puedan usarse para enmendar la última confirmación sin confirmar cambios que ya hayan sido presentados. Si se usa junto con --allow-empty, tampoco se requieren rutas y se creará una confirmación vacía.

--pathspec-from-file=<fichero>

Pasa la especificación de ruta en <fichero> y no como argumento en la línea de comandos. Si <fichero> es exactamente - entonces se usa la entrada estándar. Los elementos de la especificación de ruta se separan por LF o CR/LF. Los elementos de la especificación de ruta pueden ser entrecomillados como se explica para la variable de configuración core.quotePath (ver git-config[1]). Ver también --pathspec-file-nul y --literal-pathspecs global.

--pathspec-file-nul

Sólo significativo con --pathspec-from-file. Los elementos de la especificación de ruta se separan con el caracter NUL y todos los otros caracteres se toman literalmente (incluyendo saltos de línea y entrecomillados).

-u[<modo>]
--untracked-files[=<modo>]

Muestra los ficheros sin seguimiento.

El parámetro <modo> es opcional (predeterminado a all), y es usado para especificar el manejo de ficheros sin seguimiento; cuando no se usa -u, el predeterminado es normal, ej. muestra ficheros sin seguimiento y directorios.

Las opciones posibles son:

no

Muestra los ficheros con seguimiento

normal

Muestra ficheros sin seguimiento y directorios

all

Además muestra ficheros individuales en directorios sin seguimiento.

Todas los formas comunes de escribir el valor boleano true se toman como normal y false como no. El predeterminado puede cambiarse usando la variable de configuración status.showUntrackedFiles documentada en git-config[1].

-v
--verbose

Muestra una diferencia unificada entre HEAD de la confirmación y lo que será confirmado al final de la plantilla del mensaje de confirmación; esto para ayudarle al usuario a describir la confirmación recordándole qué cambios contiene. Nota que esta salida de diferencia no tiene sus líneas con el prefijo #. Esta diferencia no será parte del mensaje de confirmación. Ver la variable de configuración commit.verbose en git-config[1].

Si se especifica dos veces, muestra adicionalmente la diferencia unificada entre lo que será confirmado y los ficheros del árbol de trabajo, ej. los cambios no presentados a ficheros rastreados.

-q
--quiet

Suprime mensaje de resumen de confirmación.

--dry-run

No crea una confirmación, pero muestra una lista de rutas que no serán confirmadas, rutas con cambios locales que se dejarán sin confirmar y rutas que están sin seguimiento.

--status

Incluye la salida de git-status[1] en la plantilla de mensaje de confirmación cuando se usa un editor para preparar el mensaje de confirmación. Predeterminado a on, pero puede usarse para anular la variable de configuración commit.status.

--no-status

No incluye la salida de git-status[1] en la plantilla de mensaje de confirmación cuando se usa un editor para preparar el mensaje de confirmación predeterminado.

-S[<identificador-de-clave>]
--gpg-sign[=<identificador-de-clave>]
--no-gpg-sign

GPG-sign commits. The <key-id> is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. --no-gpg-sign is useful to countermand both commit.gpgSign configuration variable, and earlier --gpg-sign.

--

No interpreta ningún argumento mas como opciones.

<especificación-de-ruta>...

Cuando se da <especificación-de-ruta> en la línea de comandos, confirma el contenido de los ficheros que coinciden con la especificación de ruta sin registrar los cambios ya agregados al índice. El contenido de esos ficheros también es presentado para la siguiente confirmación por encima de lo que se ha presentado antes.

Para mas detalles, ver pathspec en gitglossary[7].

EJEMPLOS

Cuando grabas tu propio trabajo, el contenido de los ficheros modificados en tu árbol de trabajo es almacenado temporalmente en un área de presentación llamada "índice" con git add. Un fichero puede ser revertido, sólo en el índice mas no en el árbol de trabajo, hasta la última confirmación con git restore --staged <fichero>, lo cual revierte efectivamente git add y previene que los cambios a este fichero participen en la siguiente confirmación. Después de construir el estado a ser confirmado incrementalmente con esos comandos, se usa git commit(sin algún parámetro de nombre de ruta) para registrar lo que ha sido presentado al momento. Esta es la forma más básica del comando. Un ejemplo:

$ edit hola.c
$ git rm adios.c
$ git add hola.c
$ git commit

En lugar de presentar ficheros después de cada cambio individual, puedes decirle a git commit que note los cambios en los ficheros cuyo contenido tiene seguimiento en tu árbol de trabajo y haga los git add y git rm correspondientes por ti. Esto es, este ejemplo hace lo mismo que el ejemplo anterior si no hay otro cambio en tu árbol de trabajo:

$ edit hola.c
$ rm adios.c
$ git commit -a

El comando git commit -a mira primero en tu árbol de trabajo, nota que has modificado hola.c y removido adios.c, y realiza los gitt add y git rm por tí.

Después de presentar cambios a varios ficheros, puedes alterar el orden en que se registran los cambios, proporcionando nombres de rutas a git commit. Cuando se dan nombres de rutas, el comando hace una confirmación que sólo registra los cambios hechos a las rutas nombradas:

$ edit hola.c hola.h
$ git add hola.c hola.h
$ edit HazFichero
$ git commit HazFichero

Esto hace una confirmación que registra la modificación a HazFichero. Los cambios presentado para hola.c y hola.h no se incluyen en la confirmación resultante. Sin embargo, sus cambios no se pierden — aún están presentados y meramente retenidos. Después de la secuencia anterior, si haces:

$ git commit

la segunda confirmación registrará los cambios a hola.c y hola.h como es de esperarse.

Después que una fusión (iniciada por git merge o git pull) se detiene por conflictos, las rutas fusionadas limpiamente ya estarán presentadas para que las confirmes, y las rutas con conflicto se dejan en un estado sin fusionar. Tendrías que revisar primero qué rutas están en conflicto con git status para después arreglarlas manualmente en tu árbol de trabajo y presentar el resultado como de costumbre con git add:

$ git status | grep unmerged
unmerged: hola
$ edit hola.c
$ git add hola.c

Después de resolver conflictos y presentar el resultado, git ls-files -u dejará de mencionar la ruta en conflicto. Cuando hayas terminado, ejecuta git commit para grabar finalmente la fusión:

$ git commit

Como en el caso de grabar tus propios cambios, puedes usar la opción -a para ahorrar tecleo. Una diferencia es que durante una resolución de conflictos, no puedes usar git commit con nombres de rutas para alterar el orden en que se confirman los cambios, debido a que la fusión debe ser grabada en una sola confirmación. De hecho, el comando se niega a ejecutarse cuando se dan nombres de ruta (pero ver la opción -i).

INFORMACIÓN DE CONFIRMACIÓN

La información del autor y del confirmador se toman de las variables de ambiente siguientes, si están asignadas:

  • GIT_AUTHOR_NAME

  • GIT_AUTHOR_EMAIL

  • GIT_AUTHOR_DATE

  • GIT_COMMITTER_NAME

  • GIT_COMMITTER_EMAIL

  • GIT_COMMITTER_DATE

(nb "<", ">" y "\n" se quitan)

Por convención, los nombres de autor y confirmador son una forma de nombre personal (esto es, el nombre por el cual otros humanos se refieren a ti), aunque Git no impone o requiere una forma particular. Se puede usar Unicode arbitrario, sujeto a las restricciones listadas arriba. Este nombre no tiene efecto en la autenticación; para eso, ver la variable credential.username en git-config[1].

En caso de que (algunas de) esas variables de ambiente no son asignadas, la información se toma de los elementos de configuración user.name y user.email, o, si no están presentes, la variable de ambiente EMAIL, o, si no esta asignada, el nombre de usuario de sistema y el nombre del host usado para el correo de salida (tomado de /etc/mailname o de plano en el nombre completamente calificado del host cuando dicho fichero no existe).

author.name y committer.name y sus correspondientes opciones de correo electrónico anulan user.name y user.email si se asignan y son sobrescritos por si mismos por las variables de ambiente.

El uso típico es asignar solamente las variables user.name y user.email; las otras opciones se proporcionan para casos de uso mas complejos.

FORMATOS DE FECHA

Las variables de ambiente GIT_AUTHOR_DATE y GIT_COMMITTER_DATE soportan las formatos de fecha siguientes:

Formato interno de Git

Es <marca-de-tiempo-unix> <diferencia-zona-horaria>, donde <marca-de-tiempo-unix> es el número de segundos desde tiempo UNIX. <diferencia-zona-horaria> es una diferencia positiva o negativa desde UTC. Por ejemplo CET (que es 1 hora adelantada a UTC) es +0100.

RFC 2822

El formato estándar de fecha como se describe en el RFC 2822, por ejemplo Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Fecha y hora especificadas por el estándar ISO 8601, por ejemplo 2005-04-07T22:13:13. El parseador también acepta un espacio en lugar del caracter T. Las fracciones de segundo será ignoradas, por ejemplo 2005-04-07T22:13:13.019 se tratará como 2005-04-07T22:13:13.

Note
 Adicionalmente, la parte de fecha se acepta en los formatos siguientes: AAAA.MM.DD, MM/DD/AAAA and DD.MM.AAAA.

Además de reconocer los formatos de fecha anteriores, la opción --date tratará de encontrar sentido de otros formatos de fecha más centrados en el humano, como fechas relativas como "yesterday" o "last Friday at noon".

DISCUSIÓN

Aunque no es requerido, es una buena idea que el mensaje de confirmación comience con una sola línea corta (no mas de 50 caracteres) que resuma el cambio, seguido de una línea en blanco y luego una descripción mas detallada. El texto hasta la primer línea en blanco en un mensaje de confirmación es tratado como el título de la confirmación, y es usado en otras partes por Git. Por ejemplo, git-format-patch[1] convierte una confirmación en un correo electrónico, y usa el título en el Asunto y el resto de la confirmación en el cuerpo.

Warning

Missing es/i18n.adoc

See original version for this content.

VARIABLES DE AMBIENTE Y DE CONFIGURACIÓN

El editor utilizado para editar el mensaje de confirmación será elegido desde la variable de ambiente GIT_EDITOR, la variable de configuración core.editor, la variable de ambiente VISUAL, o la variable de ambiente EDITOR (en ese orden). Ver git-var[1] para detalles.

Warning

Missing es/includes/cmd-config-section-rest.adoc

See original version for this content.
Warning

Missing es/config/commit.adoc

See original version for this content.

GANCHOS

Este comando puede correr los ganchos commit-msg, prepare-commit-msg, pre-commit, post-commit y post-rewrite. Ver githooks[5] para mas información.

FICHEROS

$GIT_DIR/COMMIT_EDITMSG

Este fichero contiene el mensaje de una confirmación en progreso. Si git commit termina por un error antes de crear la confirmación, cualquier mensaje de confirmación que haya sido proporcionado por el usuario (ej. en una sesión de editor) estará disponible en este fichero, pero será sobrescrito por la siguiente invocación de git commit.

VER TAMBIÉN

git-add[1], git-rm[1], git-mv[1], git-merge[1], git-commit-tree[1]

GIT

Parte de la suite de git[1]

scroll-to-top