Git 🌙
Español ▾ Topics ▾ Latest version ▾ git-commit last updated in 2.46.1

NOMBRE

git-commit - Registra cambios en el repositorio

SINOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]
	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
	   [(--trailer <token>[(=|:)<value>])…​] [-S[<keyid>]]
	   [--] [<pathspec>…​]

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

Le dice al comando que presente 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 asunto compuesto de "fixup!" seguido por la línea de asunto 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 asunto 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 rebase --autosquash. La línea de asunto 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

When used with -C/-c/--amend options, or when committing after a conflicting cherry-pick, declare that the authorship of the resulting commit now belongs to the committer. This also renews the author timestamp.

--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 dado. 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. 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 el <mensaje> dado 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 del fichero dado. 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.txt

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á "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

Predeterminadamente, se ejecutan los ganchos pre-commit y commit-msg. Cuando se da cualquiera de --no-verify o -n, estos son omitidos. 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

Como --allow-empty este comando es primordialmente para ser usado por scripts de interfase de SCM foráneos. Te permite crear una confirmación con un mensaje vacío sin usar comandos plomería como git-commit-tree[1].

--cleanup=<modo>

Esta opción determina como 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.

espacio vacío

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

verbatim

No cambia el mensaje en absoluto.

scissors (tijeras)

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

El mensaje tomado de fichero con -F, de la línea de comando con -m, y del objeto confirmación con -C son normalmente usados como el mensaje de bitácora de confirmación sin modificar. Esta opción te permite editar posteriormente el mensaje tomado de esas fuentes.

--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 de post-escritura.

-i
--include

Before making a commit out of staged contents so far, stage the contents of paths given on the command line as well. This is usually not what you want unless you are concluding a conflicted merge.

-o
--only

Make a commit by taking the updated working tree contents of the paths specified on the command line, disregarding any contents that have been staged for other paths. This is the default mode of operation of git commit if any paths are given on the command line, in which case this option can be omitted. If this option is specified together with --amend, then no paths need to be specified, which can be used to amend the last commit without committing changes that have already been staged. If used together with --allow-empty paths are also not required, and an empty commit will be created.

--pathspec-from-file=<fichero>

La especificación de ruta se pasa 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 de 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 ficheros que no están sin 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

Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has. Note that this diff output doesn’t have its lines prefixed with #. This diff will not be a part of the commit message. See the commit.verbose configuration variable in git-config[1].

If specified twice, show in addition the unified diff between what would be committed and the worktree files, i.e. the unstaged changes to tracked files.

-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[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

GPG-sign commits. The keyid argument 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

When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the "index" with git add. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with git restore --staged <file>, which effectively reverts git add and prevents the changes to this file from participating in the next commit. After building the state to be committed incrementally with these commands, git commit (without any pathname parameter) is used to record what has been staged so far. This is the most basic form of the command. An example:

$ 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.

After a merge (initiated by git merge or git pull) stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with git status and after fixing them manually in your working tree, you would stage the result as usual with git add:

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

After resolving conflicts and staging the result, git ls-files -u would stop mentioning the conflicted path. When you are done, run git commit to finally record the merge:

$ git commit

As with the case to record your own changes, you can use -a option to save typing. One difference is that during a merge resolution, you cannot use git commit with pathnames to alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command refuses to run when given pathnames (but see -i option).

COMMIT INFORMATION

Author and committer information is taken from the following environment variables, if set:

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

(nb "<", ">" and "\n"s are stripped)

The author and committer names are by convention some form of a personal name (that is, the name by which other humans refer to you), although Git does not enforce or require any particular form. Arbitrary Unicode may be used, subject to the constraints listed above. This name has no effect on authentication; for that, see the credential.username variable in git-config[1].

In case (some of) these environment variables are not set, the information is taken from the configuration items user.name and user.email, or, if not present, the environment variable EMAIL, or, if that is not set, system user name and the hostname used for outgoing mail (taken from /etc/mailname and falling back to the fully qualified hostname when that file does not exist).

The author.name and committer.name and their corresponding email options override user.name and user.email if set and are overridden themselves by the environment variables.

The typical usage is to set just the user.name and user.email variables; the other options are provided for more complex use cases.

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

Though not required, it’s a good idea to begin the commit message with a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch[1] turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

Warning

Missing es/i18n.txt

See original version for this content.

ENVIRONMENT AND CONFIGURATION VARIABLES

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.txt

See original version for this content.
Warning

Missing es/config/commit.txt

See original version for this content.

GANCHOS

This command can run commit-msg, prepare-commit-msg, pre-commit, post-commit and post-rewrite hooks. See githooks[5] for more information.

FICHEROS

$GIT_DIR/COMMIT_EDITMSG

This file contains the commit message of a commit in progress. If git commit exits due to an error before creating a commit, any commit message that has been provided by the user (e.g., in an editor session) will be available in this file, but will be overwritten by the next invocation of 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