2012-04-26 15 views
8

Me gustaría saber qué guarda Git en realidad cuando mueve los archivos al estado "de transición".¿Cómo almacena el área de almacenamiento de git los archivos?

Considere la siguiente secuencia:

Se añade un nuevo archivo y comprometida con el repositorio local:

touch file.txt 
git add file.txt 
git commit 

Puedo hacer cambios en el archivo:

echo text1 > file.txt 
git add file.txt 

que entonces edite el archivo de nuevo, antes de confirmarlo:

echo text2 > file.txt 

Un git status muestra:

# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
#  modified: file.txt 
# 
# Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: file.txt 
# 

entonces cometer el archivo:

git commit file.txt 

Cómo es git capaz de manejar la nueva puesta en escena, segunda actualización a sin ser archivo.txt ¿dijo a? El resultado de "estado" parece que intentará verificar la primera revisión, pero retener los cambios no registrados sin registrarlos.

¿Hay una etapa implícita que se realice en este caso?

Respuesta

7

Piense en Git como dos cosas: commits (instantáneas de archivos) y labels (branches, entre otras cosas).

Git realmente crea una confirmación cuando git add, no cuando git commit. Por lo tanto, cuando ejecutó git add en el archivo modificado, creó una confirmación con esos cambios, y le asignó la etiqueta "provisional" a esa confirmación en particular.

Al cambiar el archivo de nuevo antes de ejecutar git commit, que ahora tiene la "puesta en escena cometer" (que no ha tenido git commit ejecutados en él aún), y los nuevos cambios en el archivo que se ha añadido ni tampoco cometido. Así es como git status puede mostrarles a ambos.

Cuando está git commit, en realidad está moviendo la etiqueta de rama actual a esa confirmación concreta (y eliminando la etiqueta "provisional"), por lo que la confirmación ya no está marcada como "provisional" sino "maestra" (o cualquier rama Actualmente estoy en)

+0

El comportamiento que observo cuando ejecuto la prueba descrita anteriormente es que envía también los contenidos no escaneados del archivo ("texto2") al repositorio. ¿Es correcta esta interpretación? Creo que enviaría la versión "en etapas" del archivo ("texto1"). Estoy confirmando que esto es lo que está en el repot al hacer un "archivo de comprobación de git.txt". –

+1

Acabo de hacer una prueba pero no obtuve sus resultados. 'mkdir gittest'' cd gittest' 'git init'' echo text 1> test.txt'' git add .' 'git commit -m 'Inicial commit''' echo text 2> test.txt' 'git add .' 'echo text 3> test.txt' En este punto, está el cambio por etapas (" texto 2 ") y el cambio no evaluado (" texto 3 "). Ahora, 'git checkout test.txt' y' cat test.txt'. Obtengo "texto 2".El cambio local se descartó con el cambio por etapas. – redhotvengeance

+0

Obtengo los mismos resultados que su secuencia de prueba. Pero si hago un 'git commit' después del paso' echo text 3> test.txt' (similar a mis pasos en la publicación original), ahí es cuando observo que git organiza implícitamente el contenido de "texto 3" y lo envía al repo. Para mayor claridad, la secuencia que hago aquí es: 'mkdir gittest'' cd gittest' 'git init'' echo text 1> test.txt'' git add .' 'git commit -m 'Initial commit''' echo text 2 > test.txt' 'git add .'' echo text 3> test.txt'' git commit -m 'new'' 'git checkout test.txt'' cat test.txt', lo que da como resultado una salida de "texto 3 ". –

4

git commit <somefiles> es equivalente a git add <somefiles> seguido de git commit. Si solo hace git commit, git confirmará todos los cambios por etapas, pero no confirmará las ediciones realizadas desde la última vez que ejecutó el archivo en cuestión.

Cuestiones relacionadas