Viewing: git-scm.com

Espaol Topics Latest version git-commit last updated in 2.55.0

Changes in the git-commit manual

2.55.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2026-06-29
2.54.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2026-04-20
2.53.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2026-02-02
2.52.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2025-11-17
2.51.1 2.51.2 no changes
2.51.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2025-08-18
2.50.1 no changes
2.50.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] 2025-06-16
2.49.1 no changes
2.49.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2025-03-14
2.46.2 2.48.2 no changes
2.46.1 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2024-09-13
2.45.1 2.46.0 no changes
2.45.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2024-04-29
2.43.2 2.44.4 no changes
2.43.1 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2024-02-09
2.43.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2023-11-20
2.38.1 2.42.4 no changes
2.38.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2022-10-02
2.35.1 2.37.7 no changes
2.35.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2022-01-24
2.34.1 2.34.8 no changes
2.34.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2021-11-15
2.33.1 2.33.8 no changes
2.33.0 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2021-08-16
2.32.1 2.32.7 no changes
2.32.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2021-06-06
2.31.1 2.31.8 no changes
2.31.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2021-03-15
2.30.1 2.30.9 no changes
2.30.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-12-27
2.27.1 2.29.3 no changes
2.27.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-06-01
2.25.2 2.26.3 no changes
2.25.1 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-02-17
2.25.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-01-13
2.24.1 2.24.4 no changes
2.24.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2019-11-04
2.23.1 2.23.4 no changes
2.23.0 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2019-08-16
2.21.1 2.22.5 no changes
2.21.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2019-02-24
2.17.0 2.20.5 no changes
2.16.6 [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2019-12-06
2.14.6 2.15.4 no changes
2.13.7 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2018-05-22
2.12.5 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2017-09-22
2.11.4 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2017-09-22
2.10.5 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-09-22
2.9.5 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-07-30
2.8.6 no changes
2.7.6 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-07-30
2.6.7 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-05-05
2.5.6 no changes
2.4.12 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-05-05
2.3.10 no changes
2.2.3 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2015-09-04
2.1.4 no changes
2.0.5 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2014-12-17

Check your version of git by running

git --version

NOMBRE

git-commit - Registra cambios en el repositorio

SINOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<modo>]] [--amend]
	   [--dry-run] <confirmacin>]
	   [-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>]]
	   [--] [<especificacin-de-ruta>…]

DESCRIPCIN

Crea una nueva confirmacin con el contenido actual del ndice y el mensaje de bitcora dado que describe los cambios. La nueva confirmacin 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:

usando git-add[1] para "agregar" incrementalmente cambios al ndice antes de usar el comando commit (Nota: incluso ficheros modificados deben ser "agregados");
usando git-rm[1] para remover ficheros del rbol de trabajo y el ndice, tambin antes de usar el comando commit;
listando ficheros como argumentos al comando commit (sin alguna de las opciones --interactive o --patch), en cuyo caso la confirmacin 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);
usando el modificador -a con el comando commit para "agregar" automticamente cambios de todos los ficheros conocidos (ej. todos los ficheros que ya estn listados en el ndice) y "remover" automticamente los ficheros en el ndice quitados del rbol de trabajo, y entonces realizar la confirmacin actual;
usando los modificadores --interactive o --patch con el comando commit para decidir uno por uno cules ficheros o pedazos debern ser parte de la confirmacin adems del contenido en el ndice, antes de finalizar la operacin. Ver la seccin ``Modo Interactivo" de git-add[1] para aprender cmo operar esos modos.

La opcin --dry-run puede usarse para obtener un resumen de lo que se incluir en cualquiera de los anteriores para la confirmacin siguiente dando el mismo conjunto de parmetros (opciones y rutas).

Si haces una confirmacin y luego encuentras un error inmediatamente despus, puedes recuperarte de l con git reset.

OPCIONES

-a
--all: Presenta automticamente 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 seleccin de parche interactiva para elegir cules cambios se confirmarn. Ver git-add[1] para detalles.
-U<n>
--unified=<n>: Genera diferencias con <n> lneas de contexto. El nmero de lneas de contexto es predeterminado a diff.context o 3 si se omite la configuracin de la variable. (-U sin <n> se acepta silenciosamente como sinnimo de -p por un accidente histrico).
--inter-hunk-context=<n>: Muestra el contexto entre pedazos de diferencia, hasta el <nmero> especificado de lneas, a modo de fusionar pedazos cercanos. Predeterminado a `diff.interHunkContext`o 0 si no se configura la opcin.

-C <confirmacin>
--reuse-message=<confirmacin>: Toma un objeto <confirmacin> existente, y reusa el mensaje de registro y la informacin de autora (incluyendo la marca de tiempo) cuando se crea la confirmacin.
-c <confirmacin>
--reedit-message=<confirmacin>: Como -C, pero con -c se invoca al editor, de tal manera que el usuario pueda editar posteriormente el mensaje de confirmacin.
--fixup=[(amend|reword):]<confirmacin>: Crea una nueva confirmacin que "arregla" <confirmacin> cuando se aplica con git rebase --autosquash. Un --fixup=<confirmacin> de plano crea una confirmacin "arreglo" que modifica el contenido de <commit> pero sin tocar su mensaje de registro. --fixup=amend:<confirmacin> es similar pero crea una confirmacin "enmieda" la cual adems reemplaza el mensaje de registro de <confirmacin> con el mensaje de la confirmacin "enmienda". --fixup=reword:<confirmacin> crea una confirmacin "enmienda" que reemplaza el mensaje de registro de <confirmacin> con su propio mensaje pero sin hacer cambios al contenido de <confirmacin>.

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

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

--fixup=reword:<confirmacin> es un atajo de --fixup=amend:<confirmacin> --only. Crea una confirmacin "amend!" con slo un mensaje de registro (ignorando cualquier cambio presentado al ndice). Cuando es aplastado por git rebase --autosquash, reemplaza el mensaje de registro de <confirmacin> sin hacer algn otro cambio.

Ninguna de las confirmaciones "fixup!" o "amend!" cambia la autora de <confirmacin> cuando es aplicado por git rebase --autosquash. Ver git-rebase[1] para detalles.
--squash=<confirmacin>: Construye un mensaje de confirmacin para usarse con git rebase --autosquash. El ttulo del mensaje de confirmacin se toma de la confirmacin especificada con un prefijo "squash!". Puede usarse con opciones adicionales de mensaje de confirmacin (-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 despus de una cherry-pick conflictiva, declara que la autora de la confirmacin resultante ahora pertenece al confirmante. Esto tambin 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 informacin de seguimiento tambin en formato corto. Ver git-status[1] para detalles.
--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 formato largo. Esta es la salida predeterminada de git-status[1]. Implica --dry-run.
-z
--null: Cuando se muestra el git-status[1] 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 opcin -z, los nombre de fichero con caracteres "inusuales" son entrecomillados como se explica para la variable de configuracin core.quotePath (ver git-config[1]).
-F <fichero>
--file=<fichero>: Toma el mensaje de confirmacin de <fichero>. Use - para leer el mensaje de la entrada estndar.
--author=<autor>: Anula el autor de la confirmacin. Especifica un autor explcito usando el formato estndar A U Tor <autor@ejemplo.com>. De lo contrario se asume <autor> como un patrn y se usa para buscar una confirmacin existente por ese autor (ej. git rev-list --all -i --author=<autor>); el autor de la confirmacin es copiado de la primer confirmacin encontrada.
--date=<fecha>: Anula la fecha de autora usada en la confirmacin.
-m <mensaje>
--message=<mensaje>: Usa <mensaje> como mensaje de confirmacin. Si se dan mltiples opciones -m, sus valores son concatenados como prrafos separados.

La opcin -m es mutuamente excluyente con -c, -C, y -F.
-t <fichero>
--template=<fichero>: Al editar el mensaje de confirmacin, inicia el editor con el contenido de <fichero>. Se usa a menudo la variable de configuracin commit.template para dar implcitamente esta opcin 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 confirmacin. Esto no surte efecto cuando el mensaje se proporciona por otros medios, ej. con las opciones -m o -F.
-s
--signoff
--no-signoff: Agrega un colofn Signed-off by por el confirmante al final del mensaje de registro de confirmacin. El significado de una aprobacin depende del proyecto al que se confirma. Por ejemplo, puede certificar que el confirmante tiene derecho a enviar el trabajo bajo la licencia del proyecto, o acepta alguna representacin del contribuyente, como un certificado de origen del desarrollador. (Ver https://developercertificate.org para el usado por los proyectos del kernel de Linux y Git.) Consulte la documentacin o los lderes del proyecto al que contribuye para entender cmo se usan las aprobaciones en ese proyecto.

La opcin --no-signoff puede usarse para contraordenar una opcin --signoff previa en la lnea de comandos.

Git no tiene (ni tendr) una variable de configuracin para habilitar la opcin de lnea de comando --signoff predeterminadamente; ver la entrada commit.signoff en gitfaq[7] para ms detalles.

--trailer <token>[(=|:)<valor>]

Especifica un par (<token>, <valor>) que ser aplicado como colofn. (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 confirmacin). Se pueden usar las variables de configuracin trailer.*(git-interpret-trailers[1]) para definir si un colofn duplicado se omite, si debe aparecer cada colofn al correr los colofones, y otros detalles.

-n

--verify

--no-verify

Evita los ganchos pre-commit y commit-msg. Ver tambin githooks[5].

--allow-empty

Usualmente registrar una confirmacin que tenga exactamente el mismo rbol como su nico antecesor es un error, y el comando te previene de hacer tal confirmacin. Esta opcin omite la seguridad, y es primordialmente para ser usada por scripts de interfase de SCM forneos.

--allow-empty-message

Crea una confirmacin con un mensaje de confirmacin vaco sin usar comandos plomera 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 cmo debera ser limpiado el mensaje de confirmacin proporcionado antes confirmar. El <modo> puede ser strip, whitespace, verbatim, scissors o default.

strip

Quita lneas vacas iniciales y finales, espacios en blanco al final, comentarios y colapsa lneas vacas 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 lnea 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 configuracin commit.cleanup (ver git-config[1]).

-e

--edit

Permite al usuario editar ms adelante el mensaje tomado de <fichero> con -F <fichero>, de la lnea de comando con -m <mensaje>, y de <confirmacin> con `-C <confirmacin>.

--no-edit

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

--amend

Reemplaza la punta de la rama actual creando una nueva confirmacin. El rbol registrado se prepara como siempre (incluyendo el efecto de las opciones -i y -o y especificaciones de ruta explcitas), y el mensaje de la confirmacin original se usa como el punto inicial, en lugar de un mensaje vaco, cuando no se especifica otro mensaje desde la lnea de comandos mediante opciones como -m, -F, -c, etc. La nueva confirmacin tiene los mismos antecesores y autor que la actual (la opcin --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 confirmacin de fusin.

Deberas entender las implicaciones de reescribir el historial si enmiendas una confirmacin que ya ha sido publicada. (ver la seccin "RECUPERANDOSE DE UN REBASE DE UPSTREAM" en git-rebase[1].)

--no-post-rewrite

Evita el gancho post-rewrite.

-i

--include

Antes de hacer una confirmacin con el contenido presentado al momento, presenta tambin el contenido de las rutas proporcionadas en la lnea de comandos. Esto no es normalmente lo que quieres, a menos que estes concluyendo una fusin con conflictos.

-o

--only

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

--pathspec-from-file=<fichero>

Pasa la especificacin de ruta en <fichero> y no como argumento en la lnea de comandos. Si <fichero> es exactamente - entonces se usa la entrada estndar. Los elementos de la especificacin de ruta se separan por LF o CR/LF. Los elementos de la especificacin de ruta pueden ser entrecomillados como se explica para la variable de configuracin core.quotePath (ver git-config[1]). Ver tambin --pathspec-file-nul y --literal-pathspecs global.

--pathspec-file-nul

Slo significativo con --pathspec-from-file. Los elementos de la especificacin de ruta se separan con el caracter NUL y todos los otros caracteres se toman literalmente (incluyendo saltos de lnea y entrecomillados).

-u[<modo>]

--untracked-files[=<modo>]

Muestra los ficheros sin seguimiento.

El parmetro <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: Adems 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 configuracin status.showUntrackedFiles documentada en git-config[1].

-v

--verbose

Muestra una diferencia unificada entre HEAD de la confirmacin y lo que ser confirmado al final de la plantilla del mensaje de confirmacin; esto para ayudarle al usuario a describir la confirmacin recordndole qu cambios contiene. Nota que esta salida de diferencia no tiene sus lneas con el prefijo #. Esta diferencia no ser parte del mensaje de confirmacin. Ver la variable de configuracin 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 confirmacin.

--dry-run

No crea una confirmacin, pero muestra una lista de rutas que no sern confirmadas, rutas con cambios locales que se dejarn sin confirmar y rutas que estn sin seguimiento.

--status

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

--no-status

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

-S[<identificador-de-clave>]

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

--no-gpg-sign

Confirmaciones firmadas con GPG. El <identificador-de-llave> es opcional y se predetermina a la identidad del confirmante; si se especifica, debe adherirse a la opcin sin un espacio. --no-gpg-sign es til para contraordenar tanto la variable de configuracin commit.gpgSign como --gpg-sign anterior.

--

No interpreta ningn argumento mas como opciones.

<especificacin-de-ruta>...

Cuando se da <especificacin-de-ruta> en la lnea de comandos, confirma el contenido de los ficheros que coinciden con la especificacin de ruta sin registrar los cambios ya agregados al ndice. El contenido de esos ficheros tambin es presentado para la siguiente confirmacin 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 presentacin llamada "ndice" con git add. Un fichero puede ser revertido, slo en el ndice mas no en el rbol de trabajo, hasta la ltima confirmacin con git restore --staged <fichero>, lo cual revierte efectivamente git add y previene que los cambios a este fichero participen en la siguiente confirmacin. Despus de construir el estado a ser confirmado incrementalmente con esos comandos, se usa git commit(sin algn parmetro de nombre de ruta) para registrar lo que ha sido presentado al momento. Esta es la forma ms bsica del comando. Un ejemplo:

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

En lugar de presentar ficheros despus 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.

Despus 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 confirmacin que slo 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 confirmacin que registra la modificacin a HazFichero. Los cambios presentado para hola.c y hola.h no se incluyen en la confirmacin resultante. Sin embargo, sus cambios no se pierden — an estn presentados y meramente retenidos. Despus de la secuencia anterior, si haces:

$ git commit

la segunda confirmacin registrar los cambios a hola.c y hola.h como es de esperarse.

Despus que una fusin (iniciada por git merge o git pull) se detiene por conflictos, las rutas fusionadas limpiamente ya estarn presentadas para que las confirmes, y las rutas con conflicto se dejan en un estado sin fusionar. Tendras que revisar primero qu rutas estn en conflicto con git status para despus 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

Despus 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 fusin:

$ git commit

Como en el caso de grabar tus propios cambios, puedes usar la opcin -a para ahorrar tecleo. Una diferencia es que durante una resolucin 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 fusin debe ser grabada en una sola confirmacin. De hecho, el comando se niega a ejecutarse cuando se dan nombres de ruta (pero ver la opcin -i).

INFORMACIN DE CONFIRMACIN

La informacin del autor y del confirmador se toman de las variables de ambiente siguientes, si estn 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 convencin, 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 autenticacin; 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 informacin se toma de los elementos de configuracin user.name y user.email, o, si no estn 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 electrnico anulan user.name y user.email si se asignan y son sobrescritos por si mismos por las variables de ambiente.

El uso tpico 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 nmero 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 estndar 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 estndar ISO 8601, por ejemplo 2005-04-07T22:13:13. El parseador tambin 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`.

Adems de reconocer los formatos de fecha anteriores, la opcin --date tratar de encontrar sentido de otros formatos de fecha ms centrados en el humano, como fechas relativas como "yesterday" o "last Friday at noon".

DISCUSIN

Aunque no es requerido, es una buena idea que el mensaje de confirmacin comience con una sola lnea corta (no mas de 50 caracteres) que resuma el cambio, seguido de una lnea en blanco y luego una descripcin mas detallada. El texto hasta la primer lnea en blanco en un mensaje de confirmacin es tratado como el ttulo de la confirmacin, y es usado en otras partes por Git. Por ejemplo, git-format-patch[1] convierte una confirmacin en un correo electrnico, y usa el ttulo en el Asunto y el resto de la confirmacin en el cuerpo.

Git es hasta cierto punto agnstico de codificacin de caracteres.

El contenido de objetos blob son secuencias de bytes sin interpretar. No hay traduccin de codificacin a nivel ncleo.
Los nombres de rutas estn codificadas en normalizacin UTF-8 desde C. Esto aplica a objetos rbol, el fichero ndice, nombres de referencias, as como los nombres de rutas en argumentos de lnea de comandos, variables de ambiente y ficheros de configuracin (.git/config (ver git-config[1]), gitignore[5], gitattributes[5] y gitmodules[5]).

Ntese que Git, al nivel de ncleo, trata los nombres de rutas simplemente como secuencias de bytes no nulos; no hay conversin de codificacin de nombre de ruta (exceptuando Mac y Windows). Por lo tanto, usar nombres de rutas no-ASCII funcionar en la mayora de las plataformas, incluso en sistemas de ficheros que usan codificaciones extendidas de ASCII legadas. Sin embargo, los repositorios creados en tales sistemas no funcionarn apropiadamente en sistemas basados en UTF-8 (p. ej. Linux, Mac, Windows) y viceversa. Adems, muchas herramientas basadas en Git simplemente asumen que los nombres estn en UTF-8 y mostrarn incorrectamente otras codificaciones.
Los mensajes de confirmacin estn tpicamente codificados en UTF-8, pero tambin se soportan otras codificaciones ASCII extendidas. Esto incluye a ISO-8859-x, CP125x y muchas otras, pero no UTF-16/32, EBCDIC y codificaciones multibyte CJK (GBK, Swift-JIS, Big5, EUC-x, CP9xx, etc.).

Aunque alentamos que los mensajes de confirmacin estn codificados en UTF-8, tanto el ncleo como porcelanas de Git estn diseados para no forzar UTF-8 en los proyectos. Si todos los participantes de un proyecto en particular encuentran ms conveniente usar codificaciones legadas, Git no lo prohibe. Sin embargo, hay algunas cosas a tener en mente.

git commit y git commit-tree emiten una advertencia si el mensaje de registro de confirmacin no parece una cadena UTF-8 vlida, a menos que digas explcitamente que tu proyecto usa una codificacin legada. La forma de hacerlo es poniendo i18n.commitEncoding en el fichero .git/config, as:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Los objetos de confirmacin creados con la configuracin de arriba registran el valor de i18n.commitEncoding en su encabezado encoding. Esto para ayudar a otras personas que lo vern despus. La falta de este encabezado implica que el mensaje de registro de confirmacin est codificado en UTF-8.
git log, git show, git blame y sus amigos buscan el encabezado encoding de un objeto confirmacin, e intentan re-codificar el mensaje de registro a UTF-8 a menos que se especifique lo contrario. Se puede especificar la codificacin de salida deseada con i18n.logOutputEncoding en el fichero .git/config, as:
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Si no se tiene esta variable de configuracin se usa en su lugar el valor de i18n.commitEncoding.

Ntese que deliberadamente decidimos no recodificar los mensajes de registro de confirmacin para forzar UTF-8 a nivel de objeto de confirmacin, porque recodificar a UTF-8 no es siempre una operacin reversible.

VARIABLES DE AMBIENTE Y DE CONFIGURACIN

El editor utilizado para editar el mensaje de confirmacin ser elegido desde la variable de ambiente GIT_EDITOR, la variable de configuracin 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.

commit.cleanup: Esta configuracin anula el predeterminado de la opcin --cleanup en git commit. Cambiar el predeterminado puede ser til cuando quieres siempre mantener lneas que comiencen con el caracter (core.commentChar, predeterminado a`#) en tu mensaje de bitcora, en cuyo caso haras `git config commit.cleanup whitespace (nota que, si haces esto, tendrs que quitar por ti mismo las lneas de ayuda que comienzan con el caracter de comentario en la plantilla de bitcora de confirmacin).
commit.gpgSign: Un booleano para especificar si todas las confirmaciones deben ser firmadas con GPG. Usar esta opcin cuando se hagan operaciones como rebase que puedan resultar en un nmero elevado de confirmaciones a firmar. Puede ser conveniente usar un agente para evitar teclear tu contrasea GPG varias veces.
commit.status: Un booleano para habilitar/deshabilitar la inclusin de informacin de estado en la plantilla de mensaje de confirmacin cuando se usa un editor para preparar el mensaje de confirmacin. Es predeterminado a true.
commit.template: Especifica el nombre de ruta de un fichero que ser usado como plantilla de nuevos mensajes de confirmacin.
commit.verbose: Un booleano o entero para especificar el nivel de verbosidad con git commit.

GANCHOS

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

FICHEROS

$GIT_DIR/COMMIT_EDITMSG: Este fichero contiene el mensaje de una confirmacin en progreso. Si git commit termina por un error antes de crear la confirmacin, cualquier mensaje de confirmacin que haya sido proporcionado por el usuario (ej. en una sesin de editor) estar disponible en este fichero, pero ser sobrescrito por la siguiente invocacin de git commit.

VER TAMBIN

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

GIT

Parte de la suite de git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands