2009-09-30 9 views
8

Como git noob lo estoy probando en un proyecto de Rails, me pregunto si es una mala práctica hacer git add . (agregar el directorio actual) antes de cada confirmación. Los tutoriales introductorios que he visto muestran que se agrega el directorio actual inicialmente, luego usando git add new_file para agregar archivos después de eso. Si agrego un montón de archivos de varios directorios diferentes, esto parece demasiado difícil.¿Mejor forma de usar git add?

Básicamente, si está agregando más de uno o dos archivos, ¿está bien utilizar git add . cada vez que deseo confirmar? ¿Está utilizando git add . lo mismo que explícitamente haciendo git add new_file por cada archivo que se ha creado desde la última confirmación?

Respuesta

11

git add . agregará todo lo que hay en la jerarquía, incluyendo nuevos archivos. Si desea rastrear todos los archivos que están en el directorio, esto está bien.

Otro uso (quizás más común) es hacer git commit -a, que agrega solo los archivos que han cambiado desde la última confirmación antes de confirmar y no incluye ningún archivo nuevo.

EDITAR: git add . no eliminará ningún archivo que se haya eliminado desde la última confirmación. Si está eliminando archivos, usaría git rm <myfile> para que git sea informado del archivo eliminado, y no olvide asegurarse de que git sepa que fue eliminado. Como se menciona en otro comentario, git commit -ase archivos de aviso que se han eliminado.

+0

Gracias James. Entonces, ¿no es ineficiente o redundante usar 'git add .' en lugar de agregar archivos de manera individual? No está mal "volver a agregar" archivos que ya se han agregado? –

+0

"volver a agregar" un archivo que no ha cambiado no tiene ningún efecto en nada, por lo que no, no está mal. No sé sobre ineficaz - git add . es instantáneo cuando lo uso, pero no sé si ese sigue siendo el caso en una jerarquía de carpetas grandes. –

+0

Sin embargo, 'git add .' agregará archivos que probablemente no deberían ser, como las copias de seguridad del editor y otras cruft efímeras al azar. – Novelocrat

4

Tal vez git-commit -a hace lo que quieres? Creará y enviará todos los archivos modificados y/o eliminados que están bajo control de versión.

4

puede utilizar git commit -a para cometer todos los cambios en los archivos que ya están en SourceControl (esto es como comandos de la confirmación de la subversión)

+0

Una explicación entre 'git commit -a' y' git add -u' estaría en orden. el uso de 'git commit -a' puede llevar a agregar sin saberlo archivos que no se pretendía. – Sukima

+0

@Sukima: 'git commit -a' solo comprometerá los archivos ya rastreados. Nunca agregará nuevos archivos sin seguimiento. – knittl

2

Además, es posible apreciar el modo interactivo ('git add -i'), lo que puede acelerar el proceso si es necesario agregar selectivamente un montón de archivos. Puede verlo en acción en this GitCast.

+0

Se ha movido o se ha reemplazado. Encontré esto en su lugar: http://blip.tv/scott-chacon/c3-add-interactive-4113507 –

+0

Gracias @adifferentben - buena captura. Actualizaré mi respuesta con tu corrección. – ewall

+0

@ewall: ¡¿Pero la respuesta no ha sido actualizada ?! el enlace sigue siendo 404. – Sukima

8

No hay nada malo con el uso de "git add ." si su .gitignore está actualizado y está seguro de que no agregará nada que no tenga la intención de rastrear. Haz un "git status" primero para verificar esto.

No recomendaría hacer esto antes de cada confirmación, sin embargo, como la mayoría de las veces (al menos para la mayoría de los casos de uso) modificará los archivos existentes y solo agregará uno o dos archivos completamente nuevos. En estos casos, "git add -u" y "git add <file>" suelen funcionar menos que con "git add ." o "git add -A", siempre debe verificar que no está agregando accidentalmente archivos nuevos que en realidad eran archivos temporales y que deberían haberse ignorado o borrado

"git add ." sería más útil cuando sabe que ha agregado muchos archivos nuevos en la jerarquía a partir del directorio actual y no desea especificarlos todos explícitamente. Debe asegurarse de que todo lo que no desea agregar se ignora correctamente.

0

Si su progreso es "de un solo hilo" o de una sola bifurcación, no hay un problema intrínseco, aunque otras opciones tienen las ventajas que otras personas han sugerido.Sin embargo, si tiene más de una "característica" en esta rama que quizás desee incorporar de manera selectiva en alguna rama relacionada, entonces este tipo de enfoque "comprometer todo cada vez" hará que haya más trabajo en ese momento. Probablemente haya otras ventajas similares (por ejemplo, usando git bisect). Si hay más de un hilo lógico para el trabajo que está sucediendo, entonces separarlos en el momento del compromiso puede pagar dividendos atractivos más adelante.

Cuestiones relacionadas