Bloqueo de files binarys con el sistema de control de versiones git

Durante un año y medio, he estado manteniendo mis ojos en la comunidad git con la esperanza de alejarme de SVN. Un problema particular que me frena es la incapacidad de bloquear files binarys. Durante el año pasado aún no he visto novedades sobre este tema. Entiendo que bloquear files 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 el file de image cuando existe la posibilidad de conflictos entre files binarys.

Para lograr los efectos del locking, se debe identificar un repository "central". Independientemente de la naturaleza distribuida de git, la mayoría de las empresas tendrá un repository "central" para un proyecto de software. Deberíamos poder marcar un file como requiriendo un locking del repository git que gobierna en una dirección específica. Tal vez esto se hace difícil porque git rastrea el contenido del file y no los files.

¿Alguno de ustedes tiene experiencia en tratar con files git y binarys que deberían estar bloqueados antes de la modificación?

NOTA: Parece que el nuevo proyecto de control de versiones distribuidas de fuente abierta de Source Gear, Veracity, tiene el locking como uno de sus objectives.

Git LFS 2.0 tiene soporte adicional para el locking de files.

Con Git LFS 2.0.0 ahora puede bloquear los files en los que está trabajando activamente, evitando que otros pasen al server GIT LFS hasta que vuelva a desbloquear los files.

Esto evitará conflictos de combinación, así como la pérdida de trabajo en files no fusionables en el nivel del sistema de files. Si bien parece contradecir la naturaleza distribuida y paralela de Git, el locking de files es una parte importante de muchos flujos de trabajo de desarrollo de software, especialmente para equipos más grandes que trabajan con activos binarys.

Subversion tiene lockings, y no son solo de asesoramiento. Se pueden aplicar utilizando el atributo svn:needs-lock (pero también se puede romper deliberadamente si es necesario). Es la solución correcta para administrar files no fusionables. La empresa para la que trabajo almacena casi todo en Subversion y usa svn:needs-lock para todos los files no fusionables.

No estoy de acuerdo con "los lockings son solo un método de comunicación". Son un método mucho más efectivo que las notifications push como el teléfono o el correo electrónico. Los lockings de Subversion son autodocumentados (quién tiene el locking). Por otro lado, si tiene que comunicarse por otros canales tradicionales de notificación push, como el correo electrónico, ¿a quién le envía la notificación? No sabe de antemano quién podría querer editar el file, especialmente en proyectos de código abierto, a less que tenga una list completa de todo su equipo de desarrollo. Entonces esos methods de comunicación tradicionales no son tan efectivos.

Un server de locking central, aunque en contra de los principios de DVCS, es el único método factible para files no fusionables. Siempre que DVCS no tenga una function de locking central, creo que mantendrá a la empresa para la que trabajo utilizando Subversion.

La mejor solución sería crear una herramienta de fusión para todos sus formattings de file binarys, pero esa es una meta a largo ploop y en curso que nunca se "terminará".

Aquí hay una lectura interesante sobre el tema.

Estoy de acuerdo en que bloquear files binarys es una característica necesaria para algunos entornos. Sin embargo, tuve un pensamiento sobre cómo implementar esto:

  • Tenga una forma de marcar un file como "locking de necesidades" (como la propiedad "svn: needs-lock").
  • Al finalizar la compra, git marcaría dicho file como de solo lectura.
  • Un nuevo command git-lock se contactaría con un server de locking central ejecutándose en algún lado para pedir permiso para bloquear.
  • Si el server de locking otorga permiso, marque el file de lectura y escritura.
  • git-add informaría al server de locking del hash de contenido del file bloqueado.
  • El server de locking observará que el hash de contenido aparezca en una confirmación en el repository principal.
  • Cuando aparezca el hash, suelte el locking.

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

Dentro de una organización en particular, este tipo de cosas podría quizás buildse utilizando una combinación adecuada de envoltorios de scripts y enlaces de confirmación.

En respuesta a la preocupación adicional de Mario con los cambios que ocurren en lugares múltiples en los binarys. Entonces, el escenario es que Alice y Bob están haciendo cambios en el mismo recurso binary al mismo time. Cada uno tiene su propio repository local, clonado desde un control remoto central.

Este es de hecho un problema potencial. Así que Alice termina primero y empuja a la twig central alice/update . Normalmente, cuando esto sucede, Alicia anuncia que debe ser revisada. Bob lo ve y lo revisa. Él puede (1) incorporar esos cambios a su versión (ramificación desde alice/update y hacer sus cambios a eso) o (2) publicar sus propios cambios en bob/update . Nuevamente, él hace un anuncio.

Ahora, si Alicia empuja a master , Bob tiene un dilema cuando saca el master e intenta fusionarse en su twig local. Sus conflictos con los de Alice. Pero nuevamente, el mismo procedimiento puede aplicarse, solo en diferentes twigs. E incluso si Bob ignora todas las advertencias y se compromete con las de Alice, siempre es posible sacar el compromiso de Alice de arreglar las cosas. Esto se convierte simplemente en un problema de comunicación.

Desde (AFAIK) los lockings de Subversion son solo de asesoramiento, un correo electrónico o post instantáneo podría servir para el mismo propósito. Pero incluso si no haces eso, Git te deja arreglarlo.

No, no hay mecanismo de locking per se. Pero un mecanismo de locking 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 locking.

Recientemente comenzamos a usar Git (utilizamos Subversion anteriormente) y he encontrado un cambio en el flujo de trabajo que podría ayudar con su problema, sin la necesidad de lockings. Aprovecha cómo se diseña git y qué tan fáciles son las twigs.

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

La forma en que "se pretende" utilizar git, cada desarrollador publica su propio repository público, del cual solicitan a otros que lo extraigan. Descubrí que los usuarios de Subversion tienen problemas con eso. Por lo tanto, en su lugar, presionamos para ramificar treees en el repository central, y cada usuario tiene su propio tree 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 count que también estoy mostrando twigs de tema, otra expresión idiota común.

Luego, en un repository local para el usuario a:

 feature1 feature2 

Y para llegar al server central (origen):

 git push origin feature1:users/a/feature1 

(Esto probablemente puede simplificarse con cambios de configuration)

De todos modos, una vez que se revisa feature1, quien sea responsable (en nuestro caso, es el desarrollador de la function, puede tener un único usuario responsable de las fusiones para dominar), hace lo siguiente:

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

La extracción hace una búsqueda (tirando de cualquier cambio maestro nuevo y la twig de características) y las actualizaciones son maestras de lo que tiene el repository central. Si el usuario a hizo su trabajo y realizó un seguimiento maestro, no debería haber problemas con la fusión.

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

También puedes aplicar aspectos de esto utilizando git hooks de forma programática, pero una vez más, todavía no he trabajado con estos, así que no puedo hablar sobre ellos.

Cuando estaba usando Subversion, configuré religiosamente la propiedad svn:needs-lock en todos los files de text binarys e incluso los difíciles de editar. Nunca experimenté ningún conflicto.

Ahora, en Git, no me preocupo por tales cosas. Recuerde: los lockings en Subversion no son en realidad lockings obligatorios, son meramente herramientas de comunicación. Y adivina qué: no necesito que Subversion se comunique, puedo administrarlo bien con el correo electrónico, el teléfono y la postría instantánea.

Otra cosa que hice fue replace muchos formattings binarys con formattings de text sin formatting. Uso reStructunetworkingText 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, y así sucesivamente.

Vale la pena examinar su flujo de trabajo actual para ver si el locking de imágenes es realmente necesario. Es relativamente inusual que dos personas editen una image de manera 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 locking de files centralizado para git.

TortoiseGit admite el flujo de trabajo completo de git para que los documentos de Office deleguen diff a la propia Office. También funciona delegando a OpenOffice para formattings de OpenDocument.

No esperaría que el locking de files lo convirtiera en una característica de git. ¿En qué tipo de files binarys está interesado principalmente? ¿De verdad está interesado en bloquear los files o simplemente evitar los conflictos causados ​​por no poder fusionarlos?

Me parece recordar que alguien habló (o incluso implementó) soporte para fusionar documentos de OpenOffice en git.

¿Qué hay de los files cad? Si los files no están bloqueados, para mantenerse solo como lectura, la mayoría de los progtwigs CAD solo abrirían un cambio de bits arbitrarios, visto como un nuevo file por cualquier vcs. Entonces, en mi opinión, el locking es un medio ideal para comunicar su intención de cambiar algún file particalur. Además, impide que algunos Software obtengan acceso de escritura en primer lugar. Esto permite actualizaciones de los files locales, sin la necesidad de cerrar el software o al less todos los files por completo.

git funcionará muy bien en un entorno que no sea de equipo, en el que cada desarrollador es el único responsable de un fragment de código o file, porque en ese caso no se necesita comunicación sobre lockings.

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

Simplemente coloque un file de text en cc con el file que desea bloquear y luego haga que el gancho de actualización lo rechace.

Puede ser cierto, que reorganizar un proyecto puede ayudar a evitar lockings, pero:

  • Los equipos también están organizados por otras prioridades (location, clientes, …)
  • Las herramientas también son seleccionadas por otros objectives (compatibilidad, precio, facilidad de uso por la mayoría de los empleados)
  • Algunas herramientas (y, por lo tanto, los files binarys) no se pueden evitar, ya que simplemente no hay reemploop que pueda hacer el mismo trabajo, ajustándolo a las necesidades de la empresa por el mismo precio.

Solicitar, que toda una empresa pueda reorganizar su flujo de trabajo y replace todas sus herramientas que producen binarys, solo para poder trabajar con git, debido a la falta de lockings, suena bastante ineficiente.

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

Esta no es una solución, sino un comentario sobre por qué se necesitan mecanismos de locking. Hay algunas herramientas utilizadas en algunos campos que usan formattings binarys únicos que son absolutamente críticos para la misión y el "uso de herramientas mejores / diferentes" simplemente no es una opción. No hay herramientas alternativas viables. Los que estoy familiarizado realmente no serían candidatos para la fusión, incluso si almacenó la misma información en un formatting ASCII. Una objeción que he escuchado es que quieres poder trabajar sin connection. La herramienta particular en la que estoy pensando en realidad no funciona sin connection de todos modos debido a la necesidad de extraer licencias, así que si tengo datos en una computadora portátil, no es como si pudiera ejecutar la herramienta en un tren de todos modos. Dicho esto, lo que git proporciona si tengo una connection lenta, puedo get licencias y también desplegar cambios, pero tengo la copy local rápida para search diferentes versiones. Eso es algo bueno que el DVCS le brinda incluso en este caso.

Un punto de vista es que git simplemente no es la herramienta para usar, pero es bueno para todos los files de text que también se manejan con él y es molesto necesitar diferentes herramientas de control de versiones para diferentes files.

El enfoque de sort-of-advisory-locking-a-mail realmente apesta. Lo he visto y he estado cansado de un flujo interminable de correos electrónicos de "Lo estoy editando", "He terminado de editar" y he visto cambios perdidos por eso. El caso particular en el que estoy pensando fue uno en el que una colección de files ascii más pequeños hubiera sido mucho más agradable, pero eso es un lado.

No estoy sugiriendo usar git en mi compañía por el mismo problema. Usamos EA para todos nuestros layouts y Microsoft Word Word para documentation, no sabemos de antemano quién puede editar un file en particular, por lo que el locking exclusivo es nuestra única opción.

Git no proporciona ningún command para bloquear files, pero he financiado una forma de lograr esa function usando git hooks. Se necesita un server auxiliar para almacenar la información de locking. Podemos usar un gancho precompromiso para verificar si alguno de los files comprometidos está bloqueado. Y si alguien bloquea un file, un progtwig debería decirle al server auxiliar la información del casillero y el file bloqueado.