work - ¿Son múltiples `.gitignore`s fruncidos el ceño?

gitignore folder and subfolders (5)

Como nota tangencial, un caso donde la capacidad de tener múltiples archivos .gitignore es muy útil es si desea un directorio adicional en su copia de trabajo que nunca tenga la intención de comprometer. Simplemente ponga un .gitignore 1 byte (que contenga solo un asterisco) en ese directorio y nunca aparecerá en git status etc.

A menos que un repositorio consistiera de varios proyectos independientes, parece que sería más simple tener un .gitignore archivo .gitignore en la raíz del repositorio que varios en todo el proceso. ¿Existe una mejor práctica estándar sobre este o algún análisis en línea de cuándo un enfoque es mejor que el otro?

Hay muchos escenarios en los que desea enviar un directorio a su repo de Git pero sin los archivos, por ejemplo, los logs , la cache , los directorios de uploads , etc.

Entonces, lo que siempre hago es agregar un archivo .gitignore en esos directorios con el siguiente contenido:

* !.gitignore

Con este archivo .gitignore , Git no rastreará ningún archivo en esos directorios y aún así me permitirá agregar el archivo .gitignore y, por lo tanto, el directorio al repositorio.

Puede tener múltiples .gitignore , cada uno por supuesto en su propio directorio.
Para verificar qué regla de gitignore es responsable de ignorar un archivo, use git check-ignore : git check-ignore -v -- afile .

Y puede tener una versión diferente de un archivo .gitignore por rama: ya he visto ese tipo de configuración para garantizar que una rama ignore un archivo mientras que la otra rama no: vea esta pregunta, por ejemplo .

Si su repos incluye varios proyectos independientes, sería mejor hacer referencia a ellos como submódulos .
Ésas serían las mejores prácticas reales, permitiendo que cada uno de esos proyectos se .gitignore forma independiente (con sus respectivos archivos .gitignore ), a la vez que se hace referencia a ellos mediante una revisión específica en un proyecto principal global.
Vea la verdadera naturaleza de los submódulos para obtener más información.

Tenga en cuenta que, desde git 1.8.2 (marzo de 2013), puede hacer un git check-ignore -v -- yourfile para ver qué gitignore ejecutar (desde el cual archivo .gitignore ) se aplica a '' yourfile '', y comprender mejor por qué dicho archivo es ignorado.
Consulte "¿ qué regla de gitignore está ignorando mi archivo? "

Puedo pensar en al menos dos situaciones en las que te gustaría tener múltiples archivos .gitignore en diferentes (sub) directorios.

Diferentes directorios tienen diferentes tipos de archivos para ignorar. Por ejemplo, .gitignore en el directorio superior de su proyecto ignora los programas generados, mientras que Documentation/.gitignore ignora la documentación generada.
Ignore los archivos dados solo en un directorio (sub) dado (puede usar /sub/foo en .gitignore , sin embargo).

Recuerde que los patrones en el archivo .gitignore aplican recursivamente al (sub) directorio donde se encuentra el archivo y todos sus subdirectorios, a menos que el patrón contenga ''/'' (por ejemplo, el name patrón name aplica a cualquier nombre de archivo en el directorio y todos sus subdirectorios, while /name appliest para archivar con este nombre solo en el directorio dado).

Pro solo

Fácil de encontrar.
Buscar reglas de exclusión puede ser bastante difícil si tengo varios gitignores, en varios niveles en el repositorio.
Con varios archivos, normalmente terminas con un poco de duplicación.

Pro múltiple

Lleva el "conocimiento" a la parte del árbol de archivos donde se necesita.
Como Git solo rastrea archivos, un .gitignore vacío es la única manera de enviar un directorio "vacío".
(Y antes de Git 1.8, la única forma de excluir un patrón como my/**.example era crear my/.gitignore con el patrón **.foo . Esta razón no se aplica ahora, como puede hacer /my/**/*.example ).

Prefiero un solo archivo, donde puedo encontrar todas las exclusiones. Nunca me he perdido el .svn por directorio, y tampoco me perderé el .gitignore por directorio.

Dicho esto, múltiples gitombreres son bastante comunes. Si los usa, al menos sean consistentes en su uso para que sea razonable trabajar con ellos. Por ejemplo, puede colocarlos en directorios de un solo nivel desde la raíz.