Es más fácil entender el uso de los comandos git add
y commit
si imagina que se está manteniendo un archivo de registro en su repositorio en Github. archivo de registro de un proyecto típico para mí puede ser:
---------------- Day 1 --------------------
Message: Completed Task A
Index of files changed: File1, File2
Message: Completed Task B
Index of files changed: File2, File3
-------------------------------------------
---------------- Day 2 --------------------
Message: Corrected typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on
Por lo general comienzan el día con una solicitud git pull
y terminar con una petición git push
. Entonces, todo lo que está dentro del registro de un día corresponde a lo que ocurre entre ellos. Durante cada día, hay una o más tareas lógicas que completa, que requieren el cambio de algunos archivos. Los archivos editados durante esa tarea se enumeran en un índice.
Cada una de estas subtareas (Tarea A y Tarea B aquí) son confirmaciones individuales. El comando git add
agrega archivos a la lista 'Índice de archivos modificados'. Este proceso también se denomina estadificación. El comando git commit
registra/finaliza los cambios y la lista de índice correspondiente junto con un mensaje personalizado.
Recuerde que solo está cambiando la copia local de su repositorio y no la de Github. Después de esto, solo cuando haces un 'git push', todos estos cambios registrados, junto con tus archivos de índice para cada confirmación, se registran en el repositorio principal (en Github).
A modo de ejemplo, para obtener la segunda entrada en ese archivo de registro imaginario, lo habría hecho:
git pull
# Make changes to these files
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Corrected typos'
git push
En pocas palabras, git add
y git commit
le permite desglosar un cambio en el repositorio principal en sistemática subcambios lógicos. Como otras respuestas y comentarios han señalado, por supuesto que hay muchos más usos para ellos. Sin embargo, este es uno de los usos más comunes y un principio de conducción detrás de que Git sea un sistema de control de revisiones de varias etapas a diferencia de otros populares como Svn.
No. Un archivo rastreado es aquel que tiene el repositorio conocido (normalmente de una confirmación previa) . Un archivo en etapas es uno que se ha agregado al índice, que luego se usará para confirmar. –