Close

git commit

El comando git commit captura una instantánea de los cambios preparados en ese momento del proyecto. Las instantáneas confirmadas pueden considerarse como versiones "seguras" de un proyecto: Git no las cambiará nunca a no ser que se lo pidas expresamente. Antes de ejecutar git commit, se utiliza el comando git add para pasar o "preparar" los cambios en el proyecto que se almacenarán en una confirmación. Estos dos comandos, git commit y git add, son dos de los que se utilizan más frecuentemente.


Git commit frente a SVN commit


Aunque comparten el mismo nombre, git commit no tiene nada que ver con svn commit. Este término compartido puede ser una fuente de confusión para los principiantes de Git que tienen experiencia en SVN, y es importante recalcar la diferencia. Comparar git commit con svn commit equivale a comparar un modelo de aplicaciones centralizadas (SVN) con un modelo de aplicaciones distribuidas (Git). En SVN, una confirmación envía los cambios del cliente SVN local a un repositorio SVN compartido, centralizado y remoto. En Git, los repositorios están distribuidos, las instantáneas se confirman en el repositorio local y no se requiere ninguna interacción en absoluto con otros repositorios de Git. Las confirmaciones de Git se pueden enviar más tarde a repositorios remotos arbitrarios.

Funcionamiento


A grandes rasgos, a Git se puede concebir como una utilidad de gestión de cronogramas. Las confirmaciones son las unidades básicas más importantes de un cronograma de proyecto de Git. Las confirmaciones se pueden concebir como instantáneas o hitos en el cronograma de un proyecto de Git. Las confirmaciones se crean con el comando git commit para capturar el estado de un proyecto en ese determinado momento. Las instantáneas de Git siempre se confirman en el repositorio local. Este enfoque es diametralmente opuesto al de SVN, donde la copia de trabajo se confirma en el repositorio central. Por el contrario, Git no te obliga a interactuar con el repositorio central hasta que estés listo. Del mismo modo que el entorno de ensayo es una zona intermedia entre el directorio de trabajo y el historial del proyecto, el repositorio local de cada desarrollador es una zona intermedia entre sus contribuciones y el repositorio central.

Esto cambia el modelo de desarrollo básico para los usuarios de Git. En vez de hacer un cambio y confirmarlo directamente en el repositorio central, los desarrolladores de Git tienen la oportunidad de acumular confirmaciones en su repositorio local. Esto presenta muchas ventajas con respecto a la colaboración al estilo de SVN: hace que sea más sencillo dividir una función en confirmaciones más pequeñas, mantener las confirmaciones relacionadas agrupadas y limpiar el historial local antes de publicarlo en el repositorio central. Asimismo, permite que los desarrolladores trabajen en un entorno aislado y aplacen la integración hasta que estén en un momento adecuado para fusionar su trabajo con el de otros usuarios. Aunque el aislamiento y la integración aplazada son beneficiosos para un desarrollador, por el bien de todo el equipo se debería integrar con frecuencia y en pequeñas unidades. Para obtener más información sobre las prácticas recomendadas para la colaboración en equipo en Git, lee cómo los equipos estructuran su flujo de trabajo de Git.

rama de git
Material relacionado

rama de git

Logotipo de Bitbucket
VER LA SOLUCIÓN

Aprende a usar Git con Bitbucket Cloud

Instantáneas, no diferencias


Aparte de las distinciones prácticas entre SVN y Git, su implementación subyacente también sigue filosofías de diseño completamente divergentes. Mientras que SVN monitoriza las diferencias de un archivo, el modelo de control de versiones de Git se basa en instantáneas. Por ejemplo, una confirmación SVN se compone de las diferencias en comparación con el archivo original que se ha añadido al repositorio. Por el contrario, Git registra todo el contenido de cada archivo en todas las confirmaciones.

Tutorial de Git: Instantáneas, no diferencias

Esto hace que muchas operaciones de Git sean más rápidas que las de SVN, ya que una versión particular de un archivo no se tiene que "montar" a partir de sus diferencias: la revisión completa de cada archivo está disponible inmediatamente en la base de datos interna de Git.

El modelo de instantáneas de Git tiene un alcance transcendental en prácticamente todos los aspectos de su modelo de control de versiones, que afecta a todo, desde sus herramientas de ramificación y fusión hasta sus flujos de trabajo de colaboración.

Opciones comunes


git commit

Confirma la instantánea preparada. El comando abrirá un editor de texto que te pedirá un mensaje para la confirmación. Una vez escrito el mensaje, guarda el archivo y cierra el editor para crear la confirmación.

git commit -a

Confirma una instantánea de todos los cambios del directorio de trabajo. Esta acción solo incluye las modificaciones a los archivos con seguimiento (los que se han añadido con git add en algún punto de su historial).

git commit -m "commit message"

Un comando de atajo que crea inmediatamente una confirmación con un mensaje de confirmación usado. De manera predeterminada, git commit abrirá el editor de texto configurado localmente y solicitará que se introduzca un mensaje de confirmación. Si se usa la opción -m, se omitirá la solicitud de editor de texto a favor de un mensaje insertado.

git commit -am "commit message"

Un comando de atajo para usuarios avanzados que combina las opciones -a y -m. Esta combinación crea inmediatamente una confirmación de todos los cambios preparados y aplica un mensaje de confirmación insertado.

git commit --amend

Esta opción añade otro nivel de funcionalidad al comando confirmado. Al pasar esta opción, se modificará la última confirmación. En vez de crear una nueva confirmación, los cambios preparados se añadirán a la confirmación anterior. Este comando abrirá el editor de texto configurado del sistema y te pedirá que cambies el mensaje de confirmación especificado anteriormente.

Ejemplos


Cómo guardar cambios con una confirmación

En el siguiente ejemplo, se presupone que has editado contenido en un archivo llamado hello.py en la rama actual y estás en disposición de confirmarlo en el historial del proyecto. En primer lugar, tienes que preparar el archivo con git add y después puedes confirmar la instantánea preparada.

git add hello.py

Este comando añadirá hello.py al entorno de ensayo de Git. Podemos examinar el resultado de esta acción mediante el comando git status.

git status
On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
   new file: hello.py

El resultado verde "new file: hello.py" indica que hello.py se guardará con la próxima confirmación. Desde la confirmación, se crea ejecutando lo siguiente:

git commit

Esta acción abrirá un editor de texto (personalizable mediante git config) que solicitará un mensaje de registro de confirmación, junto con una lista de lo que se va a confirmar:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch main
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
#modified: hello.py

Git no exige que los mensajes de confirmación sigan ninguna limitación de formato específica, pero el formato canónico consiste en resumir toda la confirmación en la primera línea en menos de 50 caracteres, dejar una línea en blanco y, después, una explicación detallada de lo que ha cambiado. Por ejemplo:

Change the message displayed by hello.py

- Update the sayHello() function to output the user's name
- Change the sayGoodbye() function to a friendlier message

Es una práctica habitual utilizar la primera línea del mensaje de confirmación como asunto, de forma similar a un correo electrónico. El resto del mensaje de registro se considera el cuerpo y se utiliza para comunicar los detalles del conjunto de cambios de confirmación. Ten en cuenta que a muchos desarrolladores también les gusta usar el tiempo presente en sus mensajes de confirmación. Esto hace que se lean más como acciones del repositorio, lo que hace que muchas de las operaciones de reescritura del historial sean más intuitivas.

Cómo actualizar (modificar) una confirmación


Continuemos con el ejemplo de hello.py anterior. Vamos a hacer más actualizaciones en hello.py y a ejecutar lo siguiente:

git add hello.py
git commit --amend

Esto abrirá una vez más el editor de texto configurado. Sin embargo, esta vez estará prerrellenado con el mensaje de confirmación que hemos introducido anteriormente. Indica que no estamos creando una nueva confirmación, sino editando la última.

Resumen


El comando git commit es una de las funciones esenciales principales de Git. Se requiere utilizar primero el comando git add para seleccionar los cambios que se prepararán para la siguiente confirmación. A continuación, se utiliza git commit para crear una instantánea de los cambios preparados en un cronograma de un historial de proyectos de Git. Encontrarás más información sobre cómo usar git add en la página dedicada a esa función. El comando git status permite examinar el estado del entorno de ensayo y la confirmación pendiente.

A pesar de que los modelos de confirmación de SVN y Git son significativamente diferentes, a menudo se confunden debido a la terminología que comparten. Si has llegado a Git después de haber estado utilizando SVN, es bueno que sepas que en Git las confirmaciones son fáciles y deberían usarse con frecuencia. Mientras que las confirmaciones de SVN son una operación costosa que realiza una solicitud remota, las confirmaciones de Git se hacen localmente y con un algoritmo más eficaz.


Compartir este artículo
Tema siguiente

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Gente que colabora utilizando un muro lleno de herramientas

Blog de Bitbucket

Ilustración de Devops

Ruta de aprendizaje de DevOps

Demostraciones de funciones con expertos de Atlassian del Centro de demostraciones

Cómo funciona Bitbucket Cloud con Atlassian Open DevOps

Suscríbete para recibir el boletín de DevOps

Thank you for signing up