Flujo de trabajo: uso de formatos de documentos binarios en Git sin bloqueos (pasar de subversion)

Somos una consultora de software con multitud de proyectos para diferentes clientes. Tradicionalmente usamos Subversion, pero actualmente estamos considerando mudarnos a Git.

Una parte importante de los documentos que producimos se comparte con nuestros clientes (requisitos, diseños globales, especificaciones de prueba, etc.), y usamos MS Office para producirlos. En Subversion, podríamos usar su función "Bloquear" para asegurarnos de que nadie estaba editando el mismo documento al mismo tiempo. En Git, no puedes hacer eso ya que por su naturaleza distribuida, git no tiene bloqueos.

Las cerraduras son realmente poco más que un mecanismo de comunicación, pero son muy efectivas.

Actualmente, nuestro código y los documentos orientados al cliente están típicamente en diferentes subcarpetas de un repositorio svn diferente. Al pasar a git, ¿qué recomendarías que hagamos? Veo un conjunto de opciones:

1. Movimos los repositorios de svn a git 1-on-1. En lugar de usar bloqueos en los archivos de Office, hacemos lo que la gente sugiere y de alguna manera intentamos cambiar nuestro flujo de trabajo para solucionarlo. Esto podría estar funcionando en una rama en cualquier edición de documento, y fusionarlo en una revisión. Este enfoque se divide, por ejemplo, en hojas de Excel que contienen información de gestión de proyectos; son fácilmente editados por los miembros del equipo (y alentamos que esto se haga), pero no están sujetos a ningún proceso de revisión formal

2. Usamos git para código y svn para documentos y gestión de proyectos. Esto tiene la desventaja de que ciertos documentos más de diseño no estarán "cerca" del código que especifica, lo que aumenta la posibilidad de que las personas se olviden de actualizarlos. Además, todos deben usar y comprender dos conjuntos de herramientas. Dicho esto, tal vez esta sea una gran oportunidad para pasar a herramientas de documentos basadas en texto (latex, markdown, HTML, lo que sea) para documentos de diseño que no estén orientados al cliente.

3. Como 1, pero pirateamos un git lockcomando que hace lo que svn lock hace por nosotros (alternar el indicador de solo lectura de manera apropiada y sincronizarlo con un servidor de alguna manera).

No compro el argumento de que los bloqueos no funcionan en un DVCS porque el sistema incluso debería funcionar cuando estás completamente desconectado. Las cerraduras de SVN también pueden anularse; Son un mecanismo de comunicación . Sin algún tipo de conexión de red, no podrá hacer que su computadora se comunique mucho.

No podemos ser la única tienda que está muy contenta con cómo svn lockencaja en nuestro flujo de trabajo, ¿verdad?

¿Alguna idea o consejo?

Encontré /programming/119444/locking-binary-files-using-git-version-control-system pero la discusión es bastante técnica; Estoy buscando formas de resolver o evitar el problema práctico de dos miembros del equipo que editan el mismo archivo binario al mismo tiempo.

Le recomendaría que permanezca con SVN para los documentos de MS Office por dos razones:

1. Ya está allí y es (en mi opinión) mejor para guardar documentos de Office (mira aquí ). Tiene muchas más herramientas de terceros para hacer esto.
2. El bloqueo, aunque se puede lograr en Git, no es "el tipo de Git de hacer las cosas". Si necesita estas características, quédese con la herramienta que le brinda la mejor solución.

Hay un dicho que me gusta que dice algo como esto: "Cuando estás sosteniendo un martillo, todo parece un clavo". El hecho de que se esté mudando a Git para guardar su código, no significa que deba usarlo para guardar sus documentos.

El control de versiones de código no es la mejor herramienta para trabajar en archivos de Office, porque son binarios y estas herramientas funcionan en la modificación a nivel de archivo.

Use una herramienta de colaboración, como MediaWiki (gratis) o Atlassian Confluence (de pago), desde la cual puede extraer fácilmente documentos de Word. O use LaTex para generar los archivos de Office.

Déjame expandir ...

Si necesita colaborar, debe adoptar un modelo que resalte las modificaciones (por ejemplo, cambiar una palabra, reformular o simplemente cambiar una fuente) a una unidad, por ejemplo, un archivo.

SVN y Git, incluso si se piensa en código, son herramientas de bajo nivel que comparan sus archivos por contenido textual. Pero el problema es que solo pueden funcionar en archivos de texto, porque no les importa la naturaleza / contenido del archivo para extraer un modelo de modificaciones de alto nivel.

Un claro ejemplo es un archivo de imagen . Aunque TortoiseMerge es una herramienta que ayuda a los usuarios de SVN mediante la comparación de las imágenes para sus modificaciones reales, lo normal VCSes ejecutar parches de contenido sobre los archivos. Dejame explicar. Una herramienta como TortoiseMerge puede decirle que una nueva versión de un archivo de imagen se cambia solo por unos pocos píxeles o luminancia si implementa un análisis HSV más complejo de los dos archivos. Puede añadir una marca de agua o cambiar color niveles, una herramienta que compara los archivos de imagen serán resaltar que las diferencias si se implementa buen algoritmo de comparación. Pero para verificar el nuevo archivo en su cliente debeproducir un delta. Un delta es un conjunto de líneas que se eliminan y líneas que se agregan al archivo. Los archivos binarios tienen ningún salto de línea si no suceda tener \r\n, o similares, en su carga útil, y en un delta si cambia un solo carácter está sustituyendo una línea entera.

Así que aquí está el problema. Los archivos binarios no son buenos para el control de versiones porque casi podría reemplazar el archivo completo para cada revisión. Considere cuando escribe archivos de Office usando MS Office y las ediciones de su colaborador con OpenOffice. Si implementan incluso una versión ligeramente diferente del algoritmo de compresión de los archivos OpenXML, terminará en archivos completamente diferentes, incluso si cambió una sola coma en el documento.

Los softwares de colaboración procesan documentos internamente en un formato basado en texto, porque el texto es lo realmente significativo para su empresa y puede calcular las diferencias o manejar conflictos. LaTex, o Markdown si lo desea, es una forma de almacenar un documento como un archivo de texto con marcado avanzado, por lo que no es como el archivo TXT clásico que no tiene control de fuente / formato.

Pero, obviamente, a sus clientes no les gustaría abrir archivos de Markdown, ¿verdad? Ok, puedes simplemente, y realmente quiero decir simplemente, usar cualquier software que actualmente sea demasiado flojo para google para convertir un documento fuente a PDF, Word o lo que sea.

Resumiendo

Si comienza a registrar archivos de texto en su control de origen, tiene un mayor control sobre el historial de archivos y puede manejar fácilmente los conflictos, especialmente sin usar bloqueos VCS.

Antes de compartir un documento oficialmente, necesita una rutina para exportar el documento de texto fuente a un archivo de Office

La separación de los dos pasos hace felices a las personas a costa de una curva de aprendizaje.

Puede usar git para esos documentos sin agregar bloqueo. Elija un flujo de trabajo git que bloquee los empujes a la rama maestra si no está en el maestro. (Hay varios flujos de trabajo para elegir). Esto evitará que las personas sobrescriban las modificaciones de los demás en los archivos de documentos binarios. Suponga que dos personas modifican el mismo documento binario. El primero que lo empuja a master recibe sus cambios. El segundo se bloquea porque su copia está detrás de la rama master. Tienen que sincronizar primero. Entonces la segunda persona se sincroniza. Mostrará un conflicto de fusión para el documento binario. Esa persona guarda su versión en algún lugar y resuelve el conflicto tomando la versión del maestro (que fue empujada por la primera persona). En este punto, los archivos de la segunda persona están actualizados con la rama maestra. Se fusionan en sus cambios al último documento binario (a mano), que luego contendrá los cambios de la primera persona y de la segunda persona. Luego, la nueva versión se empuja al maestro y se convierte en la nueva rama maestra. La fusión es un dolor, pero solo ocurre cuando hay un conflicto. Además, los cambios no se pierden ni se sobrescriben. Se detectan los conflictos y los usuarios pueden resolverlos limpiamente.

Pon tus 2 primeras soluciones juntas y no necesitas una tercera.

Si guarda sus hojas de cálculo en el disco como CSV, Excel aún las editará y luego git estará encantado de fusionarlas por usted.

Del mismo modo, puede abrir, editar y guardar sus archivos en Word si son HTML o (que Dios nos ayude) RTF. Word, por supuesto, agregará más hinchazón que texto útil, pero sigue siendo solo texto que git está feliz de combinar para usted.

Por supuesto, estas soluciones suponen que no hace uso o puede alejarse de las funciones específicas de MS, lo que en realidad solo es un problema en el lado de Excel.

A menos que, por supuesto, también requiera que Word se instale en un sistema para poder leer su documentación, lo cual es en sí mismo una perspectiva aterradora para mí ...