remove - git tag best practices

¿Qué documentos deben almacenarse en el control de versiones y cómo deben almacenarse? (7)

Acabo de vivir con el hecho de que no puedo rastrear los cambios a los formatos de archivos binarios a través de un sistema de control de versiones, pero lo uso de todos modos ya que es útil. Tenga en cuenta que, en general, la mayoría de estos tipos de archivos son productos de trabajo que se publicarán (guías de usuario, documentos, etc.)

Para los primeros artefactos del proyecto, como los requisitos y los diseños iniciales, tiendo a usar documentos de texto, no porque pueda hacer un seguimiento de los cambios, sino porque me gusta usar mi IDE.

Nunca me han "mordido" realmente por el hecho de que un cambio no se puede "diferenciar" en el control de versiones. Los comentarios de confirmación y otras pautas de documentación sobre el cambio de un documento binario importante por lo general compensan esa falta de visibilidad, ya que hay otro rastro si lo busca.

Estoy de acuerdo en que esto no es lo ideal, pero no creo que valga la pena preocuparse.

Tal vez me haya acostumbrado a la idea de un conjunto de archivos que podría rastrear tanto como quisiera.

Puse mucho en el control de versiones, pero también uso el seguimiento de defectos para algunas cosas con tiempos de vida que son temporales.

He encontrado algunas preguntas similares ( here , here y here ) sobre el almacenamiento de documentos en el control de versiones. Tengo un requisito más específico y una pregunta general. El requisito específico es que quiero usar Git. La pregunta más general es, ¿cómo deben almacenarse los documentos (para diseño, prueba, prácticas generales, consejos, etc., de un proyecto) en Git? En términos más generales, ¿qué documentos deben almacenarse?

Puedo pensar en algunas maneras:

Documentos de Word / Open Office. El nuevo Office Word tiene el formato docx, que comprime los documentos, pero también tiene un formato XML descomprimido, que se puede usar para almacenar de manera eficiente las diferencias en Git. Sin embargo, la característica diff todavía está rota, ya que los XML se aplastan en una sola línea. Esto no es mejor que almacenar un archivo binario en Git.
Wiki. ¿Qué wikis distribuidos existen por ahí? Sería como una especie de cosa de látex donde los documentos se escriben y compilan / ven como una wiki.
Látex, pero por su uso para papeles, me parece bastante inadecuado para documentos. ¿Existe una documentación equivalente? (¿Cómo se escriben las páginas de manual?)
Formatos de texto sin formato, pero esto es bastante deficiente debido a la falta de diagramas, lo que plantea otro punto.

¿Cómo se deben almacenar las imágenes? ¿En qué deberían componerse en primer lugar? Estoy desarrollando en un entorno Linux, pero algunos otros participantes en el proyecto están en Windows. ¿Qué solución multiplataforma hay que se parece a Visio? Y, por supuesto, no debe crear archivos binarios para ser almacenados en Git. Entonces, ¿cómo se relacionaría esto con la documentación? (Por ejemplo, similar a cómo Latex puede hacer referencia a otros diagramas cuando se compila.)

Al decidir qué formato de documento elige, debe asegurarse de que los miembros del equipo (¿o trabaja solo?) Se sientan cómodos trabajando con el formato en sí.

El almacenamiento no es tanto el problema como el poder ver diferencias entre versiones y la fusión. En mi experiencia, nada supera los formatos de texto que se pueden editar libremente en cualquier editor de texto. Esto excluye HTML y sobre cualquier formato basado en XML. DocBook es una excepción apenas utilizable.
Un buen wiki que puede usar cualquiera de los sistemas de control de versiones populares y configurarse de manera distribuida es IkiWiki . Con IkiWiki, el análisis de marcado se realiza en complementos, por lo que puede elegir el formato de entrada por documento. El "predeterminado", Markdown se acerca mucho a los formatos de texto plano.
Si no está satisfecho con el uso de LaTeX, no lo use. Creo que es inadecuado para tomar notas rápidas. Las páginas de manual están escritas en nroff, pero muchas personas usan otros formatos, como POD .

Algunos proyectos que se esfuerzan por ser alternativas a Visio son Kivio (KDE) y Dia (Gtk / Gnome). No he usado Visio, así que no puedo comentar sobre sus conjuntos de características. Probablemente depende del tipo de imágenes / diagramas que quieras crear. UML? Diagramas de flujo?

Git puede manejar archivos binarios así como archivos de texto. En lugar de almacenar explícitamente las diferencias, Git almacena todas las revisiones anteriores de los archivos en el repositorio. Los objetos del repositorio se comprimen para ahorrar espacio. Las diferencias se reconstruyen sobre la marcha cada vez que se solicitan.

Por lo tanto, considerando solo el espacio en disco, hay poca diferencia entre almacenar un documento de Office XML sin comprimir en Git y almacenar una versión comprimida de ese mismo documento. La única diferencia sería el rendimiento relativo de Zip frente a la compresión que Git elija usar.

La mayoría de los formatos de documentos no juegan muy bien con el control de código fuente. Casi todo lo que enumera es efectivamente un formato binario o un marcado retorcido que no difiere bien. Siempre que desee versiones de documentos y no le importe la diferencia, use el formato que desee. Prefiero los documentos de Microsoft Word porque puede usar el sistema integrado de seguimiento de cambios y comentarios para rastrear los deltas entre documentos.

En cuanto a qué documentos almacenar, recomendaría almacenar cualquier cosa que pueda usar más adelante. ¿Qué documentos podría usar alguien para continuar el proyecto en caso de que lo deje? ¿Qué documentos serían útiles para poner al día a una nueva persona? Esto significa especificaciones, pero no documentos como tablas de quemado.

Para responder a la parte wiki de tu pregunta, consulta DokuWiki . Almacena todo en archivos de texto para que sean muy fáciles de agregar a un sistema de control de fuente.

Mi empresa almacena documentos de Word en SVN y accede a ellos a través de TortoiseSVN.

Tortoise usa la función de seguimiento de cambios incorporada de Word para mostrarle una "diferencia" de dos revisiones.

Esto funciona realmente bien, pero requiere Windows y Word.

Editar:

Probablemente podrías conseguir que esto funcione con git también. Si instala TortoiseSVN, busque en %PROGRAMFILES%/TortoiseSVN/Diff-Scripts/ , verá lo que está haciendo la tortuga.

Si estás usando git, asumo que eres lo suficientemente 1337 como para hackearlo para que funcione para ti :)

Para OOo, documentos de Word y otros archivos binarios, debe echar un vistazo a pro-git http://git-scm.com/book/ch7-2.html

Para documentos de Word, intente usar RTF (formato de texto enriquecido), que es básicamente texto. Otra posibilidad sería HTML. Son texto, por lo que debería ser capaz de hacer diferencias en ellos.

La mayoría de los Wikis se distribuyen en que están diseñados para la colaboración. Creo que realmente está preguntando si hay soluciones alojadas o si tiene que administrarlas. Echa un vistazo a http://www.atlassian.com/ .