language-agnostic version-control

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



language-agnostic version-control (24)

Adicionalmente:

Estudio visual

  • * .ncb

Sería bueno tener una lista más o menos completa sobre qué archivos y / o directorios 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 configuración con información confidencial (contraseñas, claves 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

  • *.clase

Eclipse

No lo sé, y esto es lo que estoy buscando en este momento :-)

Pitón

  • * .pyc

Archivos temporales -. *. Sw? - * ~

Al igual que ha said todo lo que se genera, específicamente todo lo que genera el proceso de compilación y el entorno de desarrollo son buenos candidatos. Por ejemplo:

  • Binarios e instaladores
  • Bytecode y archivos
  • Documentos generados a partir de XML y código
  • Código generado por plantillas y generadores de código
  • Archivos de configuración IDE
  • Copia de seguridad de archivos generados por su IDE o editor

Algunas excepciones a lo anterior podrían ser:

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

Lleve bibliotecas de terceros, si necesita enviar o su compilación 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 fuentes no son muy eficientes para almacenar blobs binarios y que probablemente no podrá aprovechar las herramientas de diff de sistemas para esos archivos.

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

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 archivos 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 lista difícil de qué y qué no poner debajo solo funcionará para algunos y solo probablemente por tanto tiempo. Y, por supuesto, cuantos más archivos agregue al control de fuente, más tiempo llevará actualizar su copia de trabajo.

Algunos otros archivos / 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

Archivos temporales de los editores.

.*.sw? *~

etc.

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

Configura archivos que contienen contraseñas o cualquier otra información sensible.

Cualquier cosa que pueda ser generada por el IDE, el proceso de compilación o el proceso ejecutable binario.

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

De mis comentaristas, excluye:

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

Pero incluye:

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

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 módulos construidos para nuestro software. Un binario completo se distribuye cada dos semanas con las últimas actualizaciones.

Cualquiera que sea el idioma:

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

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

Ha pasado mucho tiempo 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 lista colaborativa muy útil de archivos .gitignore para todo tipo de proyectos e IDE que vale la pena echar un vistazo.

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

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

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

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

¡No olvide agregar el .gitignore a su repositorio 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 archivos .gitignore , si ve algún archivo o patrones faltantes en un .gitignore particular, puede abrir un PR en ese archivo con el cambio propuesto. Eche un vistazo a los rastreadores de solicitud de commit y extracción para obtener ideas.

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 directorio vacío para ser la raíz de sus fuentes locales; haces un "obtener lo último" o lo que sea que tu sistema de control de fuente lo llame para obtener copias limpias del lanzamiento que deseas construir; luego ejecuta la compilación (recuperada del control de origen) y todo se desarrolla.

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

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

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

Los archivos de configuración 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 archivos confidenciales que contienen contraseñas (por ejemplo).

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

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

  • (necesita un historial de revisiones O se crea fuera de su compilación pero forma parte de la compilación, la instalación o los medios) Y
  • no puede ser generado por el proceso de compilación que controlas Y
  • son comunes a todos los usuarios que crean el producto (sin configuración de usuario)

La lista incluye cosas como:

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

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

El problema con el uso de una lista 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.

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

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

El objetivo 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 objetivo.

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

Si tiene un entorno de tiempo de ejecución para su código (por ejemplo, bibliotecas de dependencias, versiones de compilación específicas, etc.), no coloque los paquetes en el control de origen. Mi enfoque es brutal, pero efectivo. Integro un archivo MAKE, cuyo rol es descargar (vía wget) las cosas, descomprimirlo y construir mi entorno de tiempo de ejecución.

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

La regla no es nada en el control de fuente que se genera durante el proceso de compilación.

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

los archivos que se generan no deben registrarse

*.bak producido por WinMerge.

desktop.ini es otro archivo de Windows que he visto colarse.

Una excepción:

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

Los archivos 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,
  • archivos autotools como configure o Makefile.in, creados por autoconf, automake, libtool, etc.
  • archivos de traducción o localización,
  • los archivos 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 archivos generados en control de la versión.

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

Archivos específicos del SO, generados por sus navegadores de archivos como .DS_Store y .DS_Store