¿Debería usarse Git para la documentación y la gestión de proyectos? ¿Debería el código estar en un repositorio separado?

Estoy iniciando un repositorio Git para un proyecto grupal. ¿Tiene sentido almacenar documentos en el mismo repositorio de Git que el código ? Parece que esto entra en conflicto con la naturaleza del flujo de revisión de Git .

Aquí hay un resumen de mis preguntas:

• ¿El estilo de revisión de Git será confuso si tanto el código como los documentos se registran en el mismo repositorio ? Experiencias con esto?

• ¿Es Git un buen ajuste para el control de revisión de documentación?

• NO estoy preguntando si un Sistema de Control de Revisión en general debería o no debería usarse para la documentación, debería hacerlo.

Gracias por los comentarios hasta ahora!

Almacenamos documentación en SVN todo el tiempo. De hecho, todo nuestro manual de usuario está escrito en LaTeX y almacenado en SVN. Elegimos LaTeX específicamente porque es un lenguaje basado en texto y fácil de mostrar diferencias línea por línea.

También almacenamos algunos archivos sin formato de texto, como archivos .doc de Microsoft Office, hojas de cálculo, archivos .zip, etc., cuando es necesario ... pero parte del beneficio de un RCS se pierde cuando no puede ver el incremento diffs.

La clave es realmente asegurarse de que su documentación esté bien organizada, para que las personas puedan encontrar (y actualizar) la documentación (y la fuente) cuando la necesiten.

Bueno, depende de qué formato utilice para la documentación. Si es algo basado en texto, todo está bien.

Git también puede almacenar contenido binario y puede realizar un seguimiento de las revisiones, pero la salida de diferencias no tendrá sentido.

También es posible almacenar documentación en el código en sí mismo, como perldoc pod, java también tiene algún formato / anotación para esto.

No puedo imaginar por qué crees que podría haber un problema al usar git, o cualquier otro sistema de control de versiones, para la documentación. Al igual que el código fuente, la documentación debe tener un historial completo y la capacidad de volver a una versión anterior si es necesario. Un sistema de control de versiones es perfecto para esto.

Está claro que usar algún tipo de sistema de control de versiones para almacenar documentos es un nobrainer. La parte más interesante de la pregunta es si es una buena idea almacenar documentos en la MISMA ubicación como código fuente. El posible problema aquí es que podría ser difícil establecer diferentes privilegios de acceso para el código y la documentación en ese caso. Y en muchos casos comerciales, las personas necesitarán acceso a documentos pero no al código fuente, como los departamentos de marketing o BA.

En la empresa en la que trabajo ponemos documentación en SVN. Sin embargo, después de algunos conflictos y la necesidad de compartirlo, decidimos moverlo a Mediawiki.

Al principio fue trac, después de eso se trasladó a Mediawiki porque era más fácil de usar ...

El principal problema con SVN fue la causa de compartir, teníamos un sistema de autorización para SVN.

• Tener algo más que código fuente en un repositorio es algo muy bueno.

  Agrupa todos sus recursos y convierte el proyecto en una entidad coherente y centralizada en lugar de una colección dispersa de archivos. Los colaboradores / empleados saben dónde encontrar todo, en lugar de enviar "¿Dónde cambio la documentación para la función x?" correos electrónicos

  Querrás mantener las cosas organizadas. Tener un sistema para separar el srcdel imagesdel docs. Siempre puede agregar un .gitignorea un directorio para mantener limpios el repositorio y el historial. Debido a que las confirmaciones de Git están basadas en archivos, * puede desacoplar los cambios de origen de los cambios de documentación tan fuerte como desee.

• Como otros han dicho, Git es excelente para el control de versiones de documentación siempre que esté basado en texto.

• Estoy completamente de acuerdo; la documentación debe ser versionada junto al código.

Mi credibilidad proviene de ser un usuario de GitHub y contribuir a un proyecto y explorar muchos otros. En mi experiencia, un proyecto completo y unificado es fácil de distinguir de uno medio perdido. Intento contener todos mis proyectos en directorios únicos siempre que sea posible.

Vine aquí con una pregunta similar. Venimos de un entorno SVN, donde básicamente es obvio mantener todos los materiales relacionados con un proyecto en el mismo repositorio. Debido a la naturaleza de SVN, puede verificar fácilmente partes del repositorio, por lo que si solo necesita el código fuente (por ejemplo, la implementación de un sitio web), no hay problema.

Con Git, las cosas son diferentes. Un proceso de pago siempre está en el nivel raíz, por lo que si desea poner todo en el mismo repositorio, siempre terminará con la misma estructura de directorios. Un enfoque que he encontrado es poner todo en ramas separadas, es decir, tiene ramas de código (que normalmente serían sus ramas maestras, de desarrollo, etc.) y una rama doc, que tiene su propia estructura de directorio separada. Todavía no estoy seguro de que esa sea la mejor idea, pero es una sugerencia que evita el problema que imagino está en la base de su pregunta.

Uso un wiki para documentos internos ... obtengo una revisión MÁS acceso prominente / edición fácil. Cuando la documentación no esté sincronizada, actualícela en ese momento. Para la documentación del usuario final, considere una herramienta profesional como Madcap Flare. Usan un dialecto XML para compartir, componer y transformar la documentación.

En el código, los pensamientos suelen estar separados línea por línea. Tiendo a escribir documentación con líneas suaves. Cuando confirmo esos archivos, las líneas tienen un párrafo completo. Eso no es muy útil para leer git diff. Ese es el problema que estaba tratando de resolver cuando busqué en Google y encontré esta página. Gracias a Arne Hartherz por presentarme git diff --word-diff. Puede que te guste git diff --color-wordsaún más.