Bloquear archivos binarios usando el sistema de control de versiones git

Durante un año y medio, he estado mirando a la comunidad de git con la esperanza de alejarme de SVN. Un problema particular que me frena es la imposibilidad de bloquear archivos binarios. A lo largo del año pasado, todavía no he visto novedades sobre este tema. Entiendo que bloquear archivos va en contra de los principios fundamentales del control de fuente distribuida, pero no veo cómo una empresa de desarrollo web puede aprovechar git para rastrear el código fuente y los cambios en los archivos de imagen cuando existe la posibilidad de conflictos de archivos binarios.

Para lograr los efectos del bloqueo, se debe identificar un repositorio "central". Independientemente de la naturaleza distribuida de git, la mayoría de las empresas tendrán un repositorio "central" para un proyecto de software. Deberíamos poder marcar un archivo que requiera un bloqueo del repositorio de git gobernante en una dirección específica. ¿Quizás esto se hace difícil porque git rastrea el contenido del archivo, no los archivos?

¿Alguno de ustedes tiene experiencia en el manejo de archivos git y binarios que deben bloquearse antes de la modificación?

NOTA: Parece que el nuevo proyecto de control de versiones distribuido de código abierto de Source Gear, Veracity, tiene el bloqueo como uno de sus objetivos.

Git LFS 2.0 ha agregado soporte para el bloqueo de archivos.

Con Git LFS 2.0.0 ahora puede bloquear archivos en los que está trabajando activamente, evitando que otros empujen al servidor Git LFS hasta que desbloquee los archivos nuevamente.

Esto evitará los conflictos de fusión, así como la pérdida de trabajo en archivos no fusionables a nivel del sistema de archivos. Si bien puede parecer contradecir la naturaleza distribuida y paralela de Git, el bloqueo de archivos es una parte importante de muchos flujos de trabajo de desarrollo de software, particularmente para equipos más grandes que trabajan con activos binarios.

Subversion tiene bloqueos y no son solo avisos. Se pueden aplicar mediante el svn:needs-lockatributo (pero también se pueden romper deliberadamente si es necesario). Es la solución adecuada para administrar archivos que no se pueden combinar. La empresa para la que trabajo almacena casi todo en Subversion y lo utiliza svn:needs-lockpara todos los archivos no fusionables.

No estoy de acuerdo con "las cerraduras son solo un método de comunicación". Son un método mucho más eficaz que las notificaciones push, como el teléfono o el correo electrónico. Las cerraduras de Subversion se autodocumentan (quién tiene la cerradura). Por otro lado, si tiene que comunicarse a través de otros canales tradicionales de notificación push, como el correo electrónico, ¿a quién envía la notificación? No sabe de antemano quién podría querer editar el archivo, especialmente en proyectos de código abierto, a menos que tenga una lista completa de todo su equipo de desarrollo. Entonces, esos métodos de comunicación tradicionales no son tan efectivos.

Un servidor de bloqueo central, aunque contra los principios de DVCS, es el único método factible para archivos no fusionables. Mientras DVCS no tenga una función de bloqueo central, creo que mantendrá a la empresa para la que trabajo usando Subversion.

La mejor solución sería crear una herramienta de combinación para todos sus formatos de archivos binarios, pero ese es un objetivo continuo ya largo plazo que nunca se "terminará".

Aquí hay una lectura interesante sobre el tema.

Estoy de acuerdo en que bloquear archivos binarios es una característica necesaria para algunos entornos. Sin embargo, solo pensé en cómo implementar esto:

• Tiene una forma de marcar un archivo como "need-lock" (como la propiedad "svn: needs-lock").
• Al finalizar la compra, git marcaría dicho archivo como de solo lectura.
• Un nuevo comando git-lock pondría en contacto con un servidor de bloqueo central que se ejecuta en algún lugar para pedir permiso para bloquear.
• Si el servidor de bloqueo otorga permiso, marque el archivo como lectura-escritura.
• git-add informaría al servidor de bloqueo del contenido hash del archivo bloqueado.
• El servidor de bloqueo observaría que ese hash de contenido apareciera en una confirmación en el repositorio principal.
• Cuando aparezca el hash, suelte el candado.

Esta es una idea a medias y hay agujeros potenciales en todas partes. También va en contra del espíritu de git, pero ciertamente puede ser útil en algunos contextos.

Dentro de una organización en particular, este tipo de cosas podrían tal vez construirse utilizando una combinación adecuada de envoltorios de script y ganchos de confirmación.

En respuesta a la preocupación adicional de Mario por los cambios que ocurren en varios lugares de los archivos binarios. Entonces, el escenario es que Alice y Bob están haciendo cambios en el mismo recurso binario al mismo tiempo. Cada uno tiene su propio repositorio local, clonado desde un control remoto central.

De hecho, este es un problema potencial. Entonces Alice termina primero y empuja hacia la alice/updaterama central . Normalmente, cuando esto sucede, Alice anunciaría que debería revisarse. Bob lo ve y lo revisa. Puede (1) incorporar esos cambios él mismo en su versión (ramificándose alice/updatey realizando sus cambios en ella) o (2) publicar sus propios cambios en bob/update. Una vez más, hace un anuncio.

Ahora, si Alice presiona en su masterlugar, Bob tiene un dilema cuando tira mastere intenta fusionarse en su sucursal local. Sus conflictos con los de Alice. Pero nuevamente, se puede aplicar el mismo procedimiento, solo en diferentes ramas. E incluso si Bob ignora todas las advertencias y se compromete por encima de Alice, siempre es posible sacar el compromiso de Alice para arreglar las cosas. Esto se convierte simplemente en un problema de comunicación.

Dado que (AFAIK) los bloqueos de Subversion son solo un aviso, un correo electrónico o mensaje instantáneo podría servir para el mismo propósito. Pero incluso si no lo hace, Git le permite solucionarlo.

No, no existe un mecanismo de bloqueo per se. Pero un mecanismo de bloqueo tiende a ser solo un sustituto de una buena comunicación. Creo que es por eso que los desarrolladores de Git no han agregado un mecanismo de bloqueo.

Recientemente comenzamos a usar Git (usamos Subversion anteriormente) y encontré un cambio en el flujo de trabajo que podría ayudar con su problema, sin la necesidad de bloqueos. Aprovecha el diseño de git y lo fáciles que son las ramas.

Básicamente, se reduce a empujar a una rama no maestra, hacer una revisión de esa rama y luego fusionarse con la rama maestra (o cualquiera que sea la rama de destino).

De la forma en que se "pretende" utilizar git, cada desarrollador publica su propio repositorio público, del que solicitan a otros que lo extraigan. Descubrí que los usuarios de Subversion tienen problemas con eso. Entonces, en cambio, presionamos para ramificar árboles en el repositorio central, y cada usuario tiene su propio árbol de ramificación. Por ejemplo, una jerarquía como esta podría funcionar:

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

Siéntase libre de usar su propia estructura. Tenga en cuenta que también estoy mostrando ramas temáticas, otro idioma de git común.

Luego, en un repositorio local para el usuario a:

feature1
feature2

Y para llevarlo al servidor central (origen):

git push origin feature1:users/a/feature1

(esto probablemente se pueda simplificar con cambios de configuración)

De todos modos, una vez que se revisa feature1, quien sea responsable (en nuestro caso, es el desarrollador de la función, podría tener un solo usuario responsable de las fusiones para dominar), hace lo siguiente:

git checkout master
git pull
git merge users/name/feature1
git push

El tirón hace una búsqueda (extrae cualquier nuevo cambio maestro y la rama de características) y las actualizaciones maestras de lo que tiene el repositorio central. Si el usuario hizo su trabajo y realizó un seguimiento del maestro correctamente, no debería haber problemas con la combinación.

Todo esto significa que, incluso si un usuario o un equipo remoto realiza un cambio en un recurso binario, se revisa antes de incorporarse a la rama maestra. Y hay una delineación clara (basada en el proceso) en cuanto a cuándo algo entra en la rama maestra.

También puede aplicar aspectos de esto mediante programación usando git hooks, pero nuevamente, no he trabajado con estos todavía, por lo que no puedo hablar sobre ellos.

Vale la pena examinar su flujo de trabajo actual para ver si es realmente necesario bloquear imágenes. Es relativamente inusual que dos personas editen una imagen de forma independiente, y un poco de comunicación puede ser de gran ayuda.

He discutido este tema en los grupos de discusión de git y he llegado a la conclusión de que, en este momento, no existe un método acordado de bloqueo de archivos centralizado para git.

Cuando estaba usando Subversion, establecía religiosamente la svn:needs-lockpropiedad en todos los archivos de texto binarios e incluso difíciles de editar. Yo nunca realidad, experimenté ningún conflicto.

Ahora, en Git, no me preocupo por esas cosas. Recuerde: los bloqueos en Subversion no son bloqueos obligatorios, son simplemente herramientas de comunicación. Y adivinen qué: no necesito que Subversion me comunique, puedo administrarme bien con el correo electrónico, el teléfono y la mensajería instantánea.

Otra cosa que hice fue reemplazar muchos formatos binarios con formatos de texto sin formato. Utilizo reStructuredText o LaΤ _Ε Χ en lugar de Word, CSV en lugar de Excel, ASCII-Art en lugar de Visio, YAML en lugar de bases de datos, SVG en lugar de OO Draw, abc en lugar de MIDI, etc.

Esta no es una solución, sino más bien un comentario sobre por qué se necesitan mecanismos de bloqueo. Hay algunas herramientas que se usan en algunos campos que usan formatos binarios solamente que son absolutamente críticos para la misión y "usar herramientas mejores / diferentes" simplemente no es una opción. No hay herramientas alternativas viables. Los que conozco realmente no serían candidatos para fusionarse incluso si almacenara la misma información en un formato ascii. Una objeción que he escuchado es que desea poder trabajar sin conexión. La herramienta en particular en la que estoy pensando realmente no funciona sin conexión de todos modos debido a la necesidad de obtener licencias, por lo que si tengo datos en una computadora portátil, no es que pueda ejecutar la herramienta mientras estoy en un tren de todos modos. Dicho esto, ¿qué proporciona git si tengo una conexión lenta? Puedo obtener licencias y también desplegar cambios, pero tengo la copia local rápida para ver diferentes versiones. Eso es algo bueno que el DVCS le ofrece incluso en este caso.

Un punto de vista es que git simplemente no es la herramienta a utilizar, pero es bueno para todos los archivos de texto que también se administran con él y es molesto necesitar diferentes herramientas de control de versiones para diferentes archivos.

El enfoque del tipo de bloqueo de aviso por correo realmente apesta. He visto eso y me he cansado de un flujo interminable de correos electrónicos de "Lo estoy editando" "Terminé de editar" y he visto los cambios perdidos debido a eso. El caso particular en el que estoy pensando fue uno en el que una colección de archivos ascii más pequeños hubiera sido mucho mejor, pero eso es un aparte.

No esperaría que el bloqueo de archivos se convirtiera en una característica de git. ¿Qué tipo de archivos binarios le interesan principalmente? ¿Está realmente interesado en bloquear los archivos o simplemente evitar conflictos causados ​​por no poder fusionarlos?

Me parece recordar a alguien hablando (o incluso implementando) soporte para fusionar documentos de OpenOffice en git.

¿Qué pasa con los archivos CAD? Si los archivos no están bloqueados, para que también se mantengan como de solo lectura, la mayoría de los programas CAD simplemente los abrirían y cambiarían bits arbitrarios, vistos como un archivo nuevo por cualquier vcs. Entonces, en mi opinión, el bloqueo es un medio ideal para comunicar su intención de cambiar algún archivo de particalur. Además, evita que algunos Software obtengan acceso de escritura en primer lugar. Esto permite actualizaciones de los archivos locales, sin la necesidad de cerrar el software o al menos todos los archivos por completo.

TortoiseGit admite el flujo de trabajo completo de git para documentos de Office que delegan diff en Office. Funciona también delegando a OpenOffice para formatos OpenDocument.

No estoy sugiriendo usar git en mi empresa para el mismo problema. Usamos EA para todos nuestros diseños y microsoft word para la documentación, no sabemos de antemano quién puede editar un archivo en particular, por lo que el bloqueo exclusivo es nuestra única opción.

git funcionará muy bien en un entorno que no sea de equipo en el que cada desarrollador es el único responsable de un fragmento de código o archivo, porque en ese caso no es necesaria la comunicación sobre bloqueos.

Si su organización requiere un entorno de equipo (generalmente para despojar a los desarrolladores de la seguridad laboral), use svn, git no es para usted. Svn proporciona tanto control de fuente como comunicación entre desarrolladores sobre bloqueos.

Simplemente coloque un archivo de texto en cc con el archivo que desea bloquear y luego haga que el enlace de actualización lo rechace.

Puede que sea cierto que reorganizar un proyecto puede ayudar a evitar bloqueos, pero:

• Los equipos también están organizados por otras prioridades (ubicación, clientes, ...)
• Las herramientas también son seleccionadas por otros objetivos (compatibilidad, precio, facilidad de uso por parte de la mayoría de los empleados)
• Algunas herramientas (y, por lo tanto, los archivos binarios) no se pueden evitar, ya que simplemente no hay un reemplazo que pueda hacer el mismo trabajo, que se ajuste a las necesidades de la empresa por el mismo precio.

Solicitar que toda una empresa reorganice su flujo de trabajo y reemplace todas sus herramientas que producen binarios, solo para poder trabajar con git, debido a la falta de bloqueos, suena bastante ineficiente.

Los bloqueos no encajan en la filosofía de git (que nunca se hizo para binarios), pero hay situaciones no despreciables, donde los bloqueos son la forma más eficiente de resolver tal problema.

Git no proporciona ningún comando para bloquear archivos, pero he financiado una forma de lograr esa función utilizando git hooks. Se necesita un servidor auxiliar para almacenar la información de bloqueo. Podemos usar un gancho de confirmación previa para verificar si alguno de los archivos comprometidos está bloqueado. Y si alguien bloquea un archivo, un programa debería decirle al servidor auxiliar la información del casillero y el archivo bloqueado.