El estado de git muestra "Cambios no procesados ​​para la confirmación" para los files enumerados en .gitignore?

Veamos el file .gitignore, al que agregué mllib / pom.xml y pom.xml e incluso .gitignore (que no debería ser necesario, por lo que algo anda mal …):

$head .gitignore .gitignore mllib/pom.xml pom.xml 

Entonces, veamos qué files quiere agregar git:

 $ git status Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: .gitignore modified: mllib/pom.xml modified: 

ACTUALIZAR Hay dos comentarios sobre no "ignorar el .gitignore". Pero después de eliminar el .gitignore de nuevo, obtenemos esto:

 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: .gitignore modified: mllib/pom.xml 

Entonces (a) .gitignore aparece y (b) el file específico que realmente es importante no agregar a un commit – mllib / pom.xml – también aparece.

El file .gitignore no significa lo que piensas que significa. 1

En particular, una vez que ha hecho que un file sea "conocido" para git, porque está en el índice, agregar el nombre de ese file a .gitignore no tiene ningún efecto. Git ya rastrea el file y continuará su seguimiento.

En esencia, el file .gitignore no es en realidad una list de files para ignorar. En cambio, cuando git encuentra un caso de un file "sin seguimiento" y está a punto de denunciarlo, el contenido de .gitignore es una list de nombres que debe suprimir.

Para el file .gitignore sí mismo, probablemente solo quiera git add los cambios y confirmarlos, ya que, como regla general, cualquiera que esté clonando su repository probablemente desee ignorar el mismo set de files no rastreados, por .gitignore que se debe rastrear .gitignore y controlar la versión .

Para el file XML, sin embargo, puede ser "contenido generado" que no desea controlar la versión, pero aún desea mantenerlo en el tree de trabajo. Esto es un problema, porque git ya lo está siguiendo e insistirá en continuar controlando la versión del file.

Lo que puedes hacer en este punto es eliminarlo del índice de git, pero no del tree de trabajo:

 git rm --cached mllib/pom.xml 

Está bien hasta donde sea posible (git elimina el file del índice y el próximo commit carecerá de ese file), pero crea problemas si alguna vez regresas a un commit que tiene el file, porque git verá que necesita para crear el file: está pasando de una confirmación en la que el file no existe (uno reciente) a una confirmación en la que existe (una anterior), y puede quejarse de que el contenido de ese file será destruido . O, incluso si esta parte funciona, si luego vuelve a una versión reciente, alejándose de la versión anterior, git comparará las versiones antiguas y nuevas y verá que el file se ha eliminado … y eliminará mllib/pom.xml .

Re-editar, 20 de octubre de 2016 : Usar git update-index --skip-worktree , not git update-index --assume-unchanged . Esto establece un bit más poderoso en el índice. Ver Git – Diferencia entre 'asumir-sin cambios' y 'skip-worktree' . Editar : como señaló Schwern en un comentario a continuación , puede usar git update-index --assume-unchanged para hacer que git ni siquiera mire el file en busca de cambios, en lugar de usar git rm --cached para sacarlo del índice ( ver esta respuesta para más detalles). Esto también está bien, puede que tenga que volver a hacerlo (o hacer que todos sus compañeros de trabajo lo hagan ellos mismos) en cualquier otro / nuevo clon.

(Puede recuperar de este último utilizando git show <oldrev>:mllib/pom.xml > mllib/pom.xml para volcar el file a la salida estándar y networkingirigir la salida estándar para volver a crear el file).


1 ¡Inconcebible!

(Más en serio, todos gitignore este error. Probablemente gitignore el nombre equivocado, y algo como git-screen-away-untracked podría haber sido mejor, si klunkier. Sin embargo, include un file en .gitignore tiene otros efectos secundarios: específicamente , permite a Git criticar esos files en algunos casos).