A menos que un repositorio consista en varios proyectos independientes, parece que sería más simple tener un solo .gitignorearchivo en la raíz del repositorio que varios en todo el documento. ¿Existe una mejor práctica estándar sobre esto o algún análisis en línea sobre cuándo un enfoque es mejor que el otro?
Respuestas:
Puedo pensar en al menos dos situaciones en las que desearía tener varios .gitignorearchivos en diferentes (sub) directorios.
Los diferentes directorios tienen diferentes tipos de archivos para ignorar. Por ejemplo, el .gitignoredirectorio superior de su proyecto ignora los programas generados, mientras que Documentation/.gitignoreignora la documentación generada.
Ignorar archivos dados solamente en el directorio dado (sub) (se puede utilizar /sub/fooen .gitignore, sin embargo).
Recuerde que los patrones en el .gitignorearchivo se aplican recursivamente al (sub) directorio en el que se encuentra el archivo y todos sus subdirectorios, a menos que el patrón contenga '/' (por ejemplo, el patrón se nameaplica a cualquier archivo nombrado nameen el directorio dado y todos sus subdirectorios, mientras que se /nameaplica al archivo con este nombre solo en el directorio dado).
Documentation/**/*.html(tenga en cuenta que cualquier barra ancla el patrón; /foose usa para anclar el archivo directamente en el directorio)
Como nota tangencial, un caso en el que la capacidad de tener múltiples .gitignorearchivos es muy útil es si desea un directorio adicional en su copia de trabajo que nunca tenga la intención de comprometer. Simplemente coloque un byte .gitignore(que contenga un solo asterisco) en ese directorio y nunca aparecerá en git statusetc.
printf \* > .gitignore(la limpieza es automática cuando elimina el directorio). Estoy seguro de que hay situaciones en las que .git/info/excludees la opción más adecuada, pero no muchas.
Puede tener múltiples .gitignore, cada uno por supuesto en su propio directorio.
Para comprobar cuál es la norma gitignore es responsable por ignorar un archivo, uso git check-ignore: git check-ignore -v -- afile.
Y puede tener una versión diferente de un .gitignorearchivo por rama: ya he visto ese tipo de configuración para garantizar que una rama ignore un archivo mientras que la otra no: vea esta pregunta, por ejemplo .
Si su repositorio incluye varios proyectos independientes, sería mejor hacer referencia a ellos como submódulos .
Estas serían las mejores prácticas reales, permitiendo que cada uno de esos proyectos se clone de forma independiente (con sus respectivos .gitignorearchivos), mientras 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 más.
Tenga en cuenta que, desde git 1.8.2 (marzo de 2013) puede hacer un git check-ignore -v -- yourfilepara ver a qué gitignore se ejecuta (desde qué .gitignorearchivo) se aplica ' yourfile', y comprender mejor por qué se ignora dicho archivo.
Consulte "¿ qué gitignoreregla está ignorando mi archivo? "
Pro soltero
Fácil de encontrar.
Cazar reglas de exclusión puede ser bastante difícil si tengo múltiples gitignore, en varios niveles en el repositorio.
Con múltiples archivos, también generalmente terminas con un poco de duplicación.
Pro múltiple
Alcanza el "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 confirmar un directorio "vacío".
(Y antes de Git 1.8, la única forma de excluir un patrón como my/**.exampleera crear my/.gitignorecon el patrón **.foo. Esta razón no se aplica ahora, como puede hacerlo /my/**/*.example).
Prefiero un solo archivo, donde puedo encontrar todas las exclusiones. Nunca me he perdido por directorio .svn, y tampoco voy a perder por directorio .gitignore.
Dicho esto, múltiples gitignores son bastante comunes. Si los usa, al menos sea consistente en su uso para que sea razonable trabajar con ellos. Por ejemplo, puede colocarlos en directorios a solo un nivel de la raíz.
emptyes más común cargar un solo archivo README (o un archivo llamado así).
Hay muchos escenarios en los que desee cometer un directorio para tu repositorio Git, pero sin los archivos que contiene, por ejemplo, la logs, cache, uploadsdirectorios, etc.
Entonces, lo que siempre hago es agregar un .gitignorearchivo en esos directorios con el siguiente contenido:
*
!.gitignore
Con este .gitignorearchivo, Git no rastreará ningún archivo en esos directorios y aún así me permitirá agregar el .gitignorearchivo y, por lo tanto, el directorio en sí mismo al repositorio.