Reglas de oro:
- incluyendo toda la que tiene una influencia sobre el resultado de la acumulación (opciones del compilador, codificaciones de archivo, ASCII/ajustes binarios, etc.)
- Incluir todo para que sea posible abrir el proyecto de una obtención limpia y ser capaz de compilar/ejecutar/prueba/debug/desplegarlo sin ninguna intervención manual adicional
- no se incluyen los archivos que contienen las rutas absolutas
- Evitar incluyendo personal preferencias (tamaño de pestaña, colores, posiciones de ventana)
Siga las reglas en este orden.
[Actualización] Siempre surge la pregunta de qué debería pasar con el código generado. Como regla general, siempre los pongo bajo control de versiones. Como siempre, tome esta regla con un grano de sal.
Mis razones:
de versiones código generado parece una pérdida de tiempo. Se genera ¿verdad? ¡Puedo recuperarlo presionando un botón!
¿De verdad?
Si tuviera que morder la bala y generar la misma versión exacta de alguna versión anterior sin falta, ¿cuánto esfuerzo sería? Al generar código, no solo tiene que obtener todos los archivos de entrada correctos, sino que también debe volver el tiempo atrás para el generador de código. ¿Puedes hacer eso? ¿Siempre? ¿Tan fácil como sería verificar una cierta versión del código generado si lo pusiera bajo control de versión?
E incluso si pudiera, ¿alguna vez podría estar seguro de que no se perdió algo?
Por un lado, poner código generado bajo control de versiones tiene sentido ya que hace que sea más fácil hacer lo que VCS significa: retroceder en el tiempo.
También hace que sea fácil ver las diferencias. Los generadores de código también tienen errores.Si soluciono un error y tengo 150'000 archivos generados, me ayuda mucho cuando puedo compararlos con la versión anterior para ver que a) el error desapareció yb) nada else cambió inesperadamente. Es la parte inesperada de la que debes preocuparte. Si no lo hace, hágamelo saber y me aseguraré de que nunca trabaje para mi empresa alguna vez :-)
El principal punto de dolor de los generadores de código es la estabilidad. No funciona cuando el generador de código simplemente escupe un desorden aleatorio de bytes cada vez que se ejecuta (bueno, a menos que no le importe la calidad). Los generadores de código deben ser estables y deterministic. Los ejecuta dos veces con la misma entrada y la salida debe ser idéntica al bit menos significativo.
Así que si no puede verificar el código generado porque cada ejecución del generador crea diferencias que no están allí, entonces su generador de código tiene un error. Arreglalo. Ordene el código cuando sea necesario. Usa mapas hash que conservan el orden. Haga todo lo necesario para que la salida no sea aleatoria. Al igual que lo haces en cualquier otro lugar en tu código.
El código generado que podría no estar bajo el control de versiones sería la documentación. La documentación es algo así como un objetivo suave. No importa tanto cuando regenero la versión incorrecta de los documentos (por ejemplo, tiene más o menos errores tipográficos). Pero para las versiones, podría hacer eso de todos modos para poder ver las diferencias entre lanzamientos. Puede ser útil, por ejemplo, para asegurarse de que las notas de la versión estén completas.
Tampoco compruebo los archivos JAR. Como tengo el control total sobre la versión completa y la confianza total de que puedo recuperar cualquier versión de las fuentes en un minuto y sé que tengo todo lo necesario para construirlo sin ninguna otra intervención manual, ¿por qué necesitaría la ejecutables para? Una vez más, podría tener sentido incluirlos en un repositorio de publicación especial, pero luego, mejor mantener una copia de los últimos tres años en el servidor web de su compañía para descargar. Piensa: Comparar binarios es difícil y no te dice mucho.
Vea también http://stackoverflow.com/questions/116121/do-you-keep-your-project-files-under-version-control/119377#119377 – VonC