A menos que un repositorio consistiera en varios proyectos independientes, parece que sería más simple tener un solo 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 varios `.gitignore`s mal visto?
puedo pensar en por lo menos dos situaciones en las que se quieren tener múltiples .gitignore archivos en diferentes directorios (sub).
Diferentes directorios tienen diferentes tipos de archivos para ignorar. Por ejemplo, el .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).
Por favor, recuerde que los patrones en .gitignore archivo se aplican de forma recursiva en el directorio (sub) el archivo está en y todos sus subdirectorios, a menos que el patrón contiene '/' (así por ejemplo, el patrón name se aplica a cualquier archivo llamado name en determinada directorio y todos sus subdirectorios, mientras que /name se aplica para archivar con este nombre solo en el directorio dado).
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 asegurar que una rama ignore un archivo mientras que la otra rama no: vea esto question for instance.
Si su repos incluye varios proyectos independientes, sería mejor hacer referencia a ellos como submódulos sin embargo.
Estas serían las mejores prácticas reales, permitiendo que cada uno de esos proyectos se clonen de forma independiente (con sus respectivos archivos .gitignore), a la vez que se hace referencia a una revisión específica en un proyecto principal global.
Ver true nature of submodules para más.
git check-ignore -v -- yourfile con el fin de ver qué gitignore correr (de la que
.gitignore archivo) se aplica a '
yourfile', y comprender mejor por qué dicho archivo
es ignorado
Ver "which gitignore rule is ignoring my file?"
¿Soy el único que piensa que la primera frase es divertida? (Debido a que varios archivos del mismo nombre no pueden estar en el mismo directorio) – TTT
@TTT Acepto. He editado la primera oración. Avíseme si se ve mejor. – VonC
Mucho mejor. : D Y una excelente adición de check-ignore! – TTT
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. Sólo hay que poner un 1 byte .gitignore (que contiene un solo asterisco) en ese directorio y nunca se mostrará en git status etc.
también puede usar ". git/info/exclude "file for that – Ayell
Claro, si no te molesta la dificultad de tener que abrir un archivo en un lugar fuera de la raíz del repositorio, escribir una ruta completa en él y luego recordar limpiar el entrada si/cuando eliminas el directorio. Compare eso con 'printf \ *> .gitignore' (la limpieza es automática cuando elimina el directorio). Estoy seguro de que hay situaciones en las que '.git/info/exclude' es la opción más adecuada, pero no muchas. –
Sí, cuando desea excluir un archivo en lugar de una carpeta, por ejemplo: p – Ayell
Pro sola
Es 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, también suele terminar con un poco de duplicación.
Pro múltiple
Scopes "conocimiento" a la parte del árbol de archivos donde se necesita.
Dado que Git solo rastrea archivos, un .gitignore vacío es la única forma de asignar un directorio "vacío".
(Y antes de Git 1.8, la única manera de excluir a un patrón como my/**.example era crear my/.gitignore con el patrón **.foo. Esta razón no se aplica ahora, como se 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 gitignores 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.
"un .gitignore vacío es la única manera de enviar un directorio" vacío "." De hecho, creo que es más común subir un archivo README (o un archivo llamado 'empty'). –
.gitkeep es una buena manera de hacer esto también ... solo otra convención. Me gusta la idea de usar un archivo Léame, porque entonces podría explicar para qué se usa el directorio, en ese archivo "Léame". –
Hay muchos escenarios en los que desee cometer un directorio para tu repositorio Git, pero sin los archivos que contiene, por ejemplo, los logscache, uploads directorios etc.
Así que lo que siempre hago es añadir una .gitignore archivo en esos directorios con el siguiente contenido:
*
!.gitignore
con este archivo .gitignore, Git no va a realizar un seguimiento de todos los archivos en esos directorios y aún así me permite manejar el archivo .gitignore y por lo tanto el propio directorio de t él repo.
Ah, por alguna razón, pensé que /Documentation/*.html cubriría esto, pero supongo que * wild card solo coincidirá con directorios de un nivel. –
@ConleyOwens: con Git moderno puede usar 'Documentation/**/*. Html' (tenga en cuenta que cualquier barra inclinada ancla el patrón;'/foo' se usa para anclar el archivo directamente en el directorio) –