¿Qué NO debería estar bajo el control de la fuente?

Sería bueno tener una list más o less completa sobre qué files y / o directorys no deberían (en la mayoría de los casos) estar bajo el control de la fuente. ¿Qué crees que debería ser excluido?

Sugerencia hasta el momento:

En general

  • Archivos de configuration con información confidencial (passwords, keys privadas, etc.)
  • Thumbs.db, .DS_Store y desktop.ini
  • Copias de respaldo del editor: * ~ (emacs)
  • Archivos generados (por ejemplo, salida DoxyGen)

DO#

  • compartimiento\*
  • obj \ *
  • *.exe

Estudio visual

  • * .suo
  • * .ncb
  • *.usuario
  • * .aps
  • * .cachefile
  • *.apoyo
  • _UpgradeReport_Files

Java

  • *.class

Eclipse

No lo sé, y esto es lo que estoy buscando en este momento 🙂

Pitón

  • * .pyc

Archivos temporales -. *. Sw? – * ~

Cualquier cosa que se genere Binario, bytecode, código / documentos generados a partir de XML.

De mis comentaristas, excluye:

  • Cualquier cosa generada por la compilation, incluidos los documentos de código (doxygen, javadoc, pydoc, etc.)

Pero incluye:

  • Bibliotecas de terceros que no tienen la fuente OR o no comstackn.

FWIW, en mi trabajo para un proyecto muy grande, tenemos lo siguiente en ClearCase:

  • Todo el código original
  • Qt source AND built debug / release
  • (Terriblemente anticuado) especificaciones

No tenemos modules construidos para nuestro software. Un binary completo se distribuye cada dos semanas con las últimas actualizaciones.

Archivos específicos del SO, generados por sus browseres de files como .DS_Store y .DS_Store

Algunos otros files / carpetas típicos de Visual Studio son

 *.cachefile *.backup _UpgradeReport_Files 

Mi patrón global de ignorar tortugas, por ejemplo, se parece a esto

 bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files 

los files que se generan no deben registrarse

Al igual que Corey D, ha dicho todo lo que se genera, específicamente todo lo que genera el process de compilation y el entorno de desarrollo son buenos candidatos. Por ejemplo:

  • Binarios e instaladores
  • Bytecode y files
  • Documentos generados a partir de XML y código
  • Código generado por templates y generadores de código
  • Archivos de configuration IDE
  • Copia de security de files generados por su IDE o editor

Algunas excepciones a lo anterior podrían ser:

  • Imágenes y video
  • Bibliotecas de terceros
  • Archivos de configuration IDE específicos del equipo

Lleve bibliotecas de terceros, si necesita enviar o su compilation depende de una biblioteca de terceros no sería irrazonable ponerlo bajo control de fuente, especialmente si no tiene la fuente. Además, considere que algunos sistemas de control de fonts no son muy eficientes para almacenar blobs binarys y que probablemente no podrá aprovechar las herramientas de diff de sistemas para esos files.

Paul también hace un gran comentario sobre los files generados y debes echar un vistazo a su respuesta :

Básicamente, si no puede razonablemente esperar que un desarrollador tenga la versión exacta de la herramienta exacta que necesita, existe la posibilidad de poner los files generados en control de la versión.

Con todo lo dicho en última instancia, tendrá que considerar lo que pone bajo el control de la fuente caso por caso. Definir una list difícil de qué y qué no poner debajo solo funcionará para algunos y solo probablemente por tanto time. Y, por supuesto, cuantos más files agregue al control de fuente, más time llevará actualizar su copy de trabajo.

Me acercaría al problema de otra manera; ¿Qué cosas deberían includese en el control de la fuente? Solo debe controlar los files de origen que:

  • (necesita un historial de revisiones O se crea fuera de su compilation pero forma parte de la compilation, la installation o los medios) Y
  • no puede ser generado por el process de compilation que controlas Y
  • son comunes a todos los usuarios que crean el producto (sin configuration de usuario)

La list incluye cosas como:

  • files fuente
  • files de creación, proyecto y solución
  • otros files de configuration de herramienta de compilation (no relacionados con el usuario)
  • Bibliotecas de terceros
  • files preconstruidos que van en los medios como files PDF y documentos
  • documentation
  • imágenes, videos, sonidos
  • files de descripción como WSDL, XSL

A veces, un resultado de compilation puede ser una input de compilation. Por ejemplo, un file de cambio de nombre de ofuscación puede ser un resultado y una input para mantener el mismo esquema de cambio de nombre. En este caso, use el file registrado como la input de compilation y coloque el resultado en un file diferente. Después de la compilation, revisa el file de input y copy el file de salida en él y compruébalo.

El problema con el uso de una list de exclusión es que nunca conocerá todas las exclusiones correctas y podría terminar controlando la fuente de algo que no debería ser controlado por la fuente.

Una exception:

4 o 5 respuestas diferentes han dicho que los files generados no deben pasar por control de fuente. Eso no es del todo cierto.

Los files generados por herramientas especializadas pueden pertenecer al control de fuente, especialmente si se necesitan versiones particulares de esas herramientas.

Ejemplos:

  • analizadores generados por bison / yacc / antlr,
  • files autotools como configure o Makefile.in, creados por autoconf, automake, libtool, etc.
  • files de traducción o localización,
  • los files pueden ser generados por herramientas costosas, y puede ser más barato instalarlos solo en algunas máquinas.

Básicamente, si no puede razonablemente esperar que un desarrollador tenga la versión exacta de la herramienta exacta que necesita, existe la posibilidad de poner los files generados en control de la versión.

Esta exception es discutida por los chicos de svn en su charla de mejores prácticas .

Archivos temporales de los editores.

 .*.sw? *~ 

etc.

Cualquier cosa que pueda ser generada por el IDE, el process de compilation o el process ejecutable binary.

desktop.ini es otro file de Windows que he visto queuerse.

Configura files que contienen passwords o cualquier otra información sensible.

Los files de configuration reales como web.config en asp.net porque las personas pueden tener configuraciones diferentes. Por lo general, la forma en que manejo esto es teniendo un web.config.template que está en SVN. La gente lo consigue, realiza los cambios que desea y lo renombra como web.config.

Aparte de esto y de lo que dijiste, ten cuidado con los files confidenciales que contienen passwords (por ejemplo).

Evite todos los files molestos generados por Windows (thumb) o Mac OS (.ds_store)

*.bak producido por WinMerge.

Adicionalmente:

Estudio visual

  • * .ncb

La mejor manera que he encontrado para pensar es la siguiente:

Imagina que tienes una computadora nueva, comprada en la tienda. Instalas el SO y las actualizaciones; instala todas sus herramientas de desarrollo, incluido el cliente de control de origen; usted crea un directory vacío para ser la raíz de sus fonts locales; haces un "get lo último" o lo que sea que tu sistema de control de fuente lo llame para get copys limpias del lanzamiento que deseas build; luego ejecuta la compilation (recuperada del control de origen) y todo se desarrolla.

Este process de pensamiento le dice por qué ciertos files deben estar en control de fuente: todos los necesarios para que la compilation funcione en un sistema limpio. Esto incluye los files .designer.cs, los resultados de las templates T4 y cualquier otro artefacto que la compilation no cree.

Archivos temporales, configuration para cualquier cosa que no sea desarrollo global e información sensible

Cualquiera que sea el idioma:

  • files de caching
  • en general, los files importados tampoco deberían (como las imágenes cargadas por los usuarios, en una aplicación web)
  • files temporales ; incluso los generados por su sistema operativo (como thumbs.db en windows) o IDE
  • config files con passwords? Depende de quién tenga acceso al repository

Y para aquellos que no lo saben: svn:ignore es genial!

Las cosas que no entran en control de fuente vienen en 3 classs

  1. Cosas totalmente ajenas al proyecto (obviamente)
  2. Cosas que se pueden encontrar en los medios de installation y que nunca se modifican (p. Ej .: API de terceros).
  3. Cosas que se pueden generar mecánicamente, a través de su process de compilation, a partir de cosas que están en control de fuente (o de cosas en la class 2).

Si tiene un entorno de time de ejecución para su código (por ejemplo, bibliotecas de dependencies, versiones de comstackdor específicas, etc.) no coloque los packages en el control de origen. Mi enfoque es brutal, pero efectivo. Integro un file MAKE, cuyo rol es download (vía wget) las cosas, descomprimirlo y build mi entorno de time de ejecución.

Tengo un file .c particular que no entra en control de fuente.

La regla no es nada en el control de fuente que se genera durante el process de compilation.

La única exception conocida es si una herramienta requiere una versión anterior de sí mismo para comstackr (problema de arranque). En ese caso, necesitará una buena copy de arranque conocida en el control de código fuente para que pueda comstackr desde el espacio en blanco.

Salir de una extremidad aquí, pero creo que si utiliza lists de tareas en Visual Studio, se mantienen en el file .suo. Esta puede no ser una razón para mantenerlos en control de fuente, pero es una razón para mantener una copy de security en alguna parte, por si acaso …

Opinión: todo puede estar en control de fuente, si es necesario, a less que tenga una sobrecarga de repository significativa, como cambios frecuentes o blobs grandes.

Binarios de terceros, files difíciles de generar (en términos de time) generados para acelerar su process de implementación, todos están bien.

El objective principal del control de fuente es hacer coincidir un estado de sistema coherente con un número de revisión. Si fuera posible, congelaría todo el universo con las herramientas de construcción de código y el sistema operativo objective.

Ha pasado mucho time desde que se hizo esta pregunta, y creo que muchas de las respuestas, aunque relevantes, no tienen detalles duros sobre .gitignore en un idioma o nivel de IDE.

Github .gitignore list queueborativa muy útil de files .gitignore para todo tipo de proyectos e IDE que vale la pena echar un vistazo.

Aquí hay un enlace a ese repository de git: https://github.com/github/gitignore

Para responder la pregunta, aquí están los ejemplos relacionados para:

  • C # -> ver Visual Studio
  • Estudio visual
  • Java
  • Eclipse
  • Pitón

También hay files .gitignore específicos del sistema .gitignore . Siguiendo:

  • Windows
  • OS X
  • Linux

Entonces, suponiendo que esté ejecutando Windows y usando Eclipse , puede concatenar Eclipse.gitignore y Windows.gitignore a un file .gitignore en el directory de nivel superior de su proyecto. Cosas muy ingeniosas

¡No olvide agregar el .gitignore a su repository y consignarlo!

Lo más probable es que su IDE ya maneje esto por usted. Visual Studio lo hace de todos modos.

Y para los files .gitignore , si ve algún file o patrones faltantes en un .gitignore particular, puede abrir un PR en ese file con el cambio propuesto. Eche un vistazo a los rastreadores de request de compromiso y extracción para get ideas.

    Intereting Posts