git - tipos - ventajas de usar un sistema de control de versiones

Bloqueo de archivos binarios con el sistema de control de versiones git (17)

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 archivos binarios. Durante el año pasado aún 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 el archivo de imagen cuando existe la posibilidad de conflictos entre 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á un repositorio "central" para un proyecto de software. Deberíamos poder marcar un archivo como requiriendo un bloqueo del repositorio git que gobierna en una dirección específica. Tal vez esto se hace difícil porque git rastrea el contenido del archivo y no los archivos.

¿Alguno de ustedes tiene experiencia en tratar con archivos git y binarios 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 bloqueo como uno de sus objetivos.

¿Qué hay de los archivos cad? Si los archivos no están bloqueados, para mantenerse solo como lectura, la mayoría de los programas CAD solo abrirían un cambio de bits arbitrarios, visto como un nuevo archivo por cualquier vcs. Entonces, en mi opinión, el bloqueo es un medio ideal para comunicar su intención de cambiar algún archivo particalur. Además, impide 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.

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

Ahora, en Git, no me preocupo por tales cosas. Recuerde: los bloqueos en Subversion no son en realidad bloqueos 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 mensajería instantánea.

Otra cosa que hice fue reemplazar muchos formatos binarios con formatos de texto sin formato. Uso 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, y así sucesivamente.

En respuesta a la preocupación adicional de Mario con los cambios que ocurren en lugares múltiples en los 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.

Este es de hecho un problema potencial. Así que Alice termina primero y empuja a la rama 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 rama local. Sus conflictos con los de Alice. Pero nuevamente, el mismo procedimiento puede aplicarse, solo en diferentes ramas. 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 bloqueos de Subversion son solo de asesoramiento, un correo electrónico o un mensaje 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 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.

Esta no es una solución, sino un comentario sobre por qué se necesitan mecanismos de bloqueo. Hay algunas herramientas utilizadas en algunos campos que usan formatos binarios ú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 formato ASCII. Una objeción que he escuchado es que quieres poder trabajar sin conexión. La herramienta particular en la que estoy pensando en realidad no funciona sin conexión 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 conexión lenta, puedo obtener licencias y también desplegar cambios, pero tengo la copia local rápida para buscar 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 archivos de texto que también se manejan con él y es molesto necesitar diferentes herramientas de control de versiones para diferentes archivos.

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 archivos ascii más pequeños hubiera sido mucho más agradable, pero eso es un lado.

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

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

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 contextos.

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

Git no proporciona ningún comando para bloquear archivos, pero he financiado una forma de lograr esa función usando git hooks. Se necesita un servidor auxiliar para almacenar la información de bloqueo. Podemos usar un gancho precompromiso 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.

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.

No esperaría que el bloqueo de archivos lo convirtiera en una característica de git. ¿En qué tipo de archivos binarios está interesado principalmente? ¿De verdad está interesado en bloquear los archivos 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.

No estoy sugiriendo usar git en mi compañía por el mismo problema. Usamos EA para todos nuestros diseños y Microsoft Word Word para 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.

Puede ser 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 la mayoría de los empleados)
Algunas herramientas (y, por lo tanto, los archivos binarios) no se pueden evitar, ya que simplemente no hay reemplazo 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 reemplazar 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 git (que nunca se hizo para los binarios), pero existen situaciones no despreciables, donde los bloqueos son la forma más eficiente de resolver ese problema.

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 bloqueos. Aprovecha cómo se diseña git y qué tan fáciles son las ramas.

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

La forma en que "se pretende" utilizar git, cada desarrollador publica su propio repositorio 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 á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 de tema, otra expresión idiota común.

Luego, en un repositorio local para el usuario a:

feature1 feature2

Y para llegar al servidor central (origen):

git push origin feature1:users/a/feature1

(Esto probablemente puede simplificarse 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, 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 rama de características) y las actualizaciones son maestras de lo que tiene el repositorio 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 binario, se revisa antes de que se incorpore a la rama principal. Y hay una delineación clara (basada en el proceso) sobre cuándo algo entra en la rama 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.

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

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 formatos de OpenDocument.

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

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 se necesita comunicación sobre bloqueos.

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

Git LFS 2.0 tiene soporte adicional para el bloqueo de archivos.

Con Git LFS 2.0.0 ahora puede bloquear los archivos en los que está trabajando activamente, evitando que otros pasen al servidor GIT LFS hasta que vuelva a desbloquear los archivos.
Esto evitará conflictos de combinación, así como la pérdida de trabajo en archivos no fusionables en el nivel del sistema de archivos. Si bien parece 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, especialmente para equipos más grandes que trabajan con activos binarios.

Subversion tiene bloqueos, 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 archivos no fusionables. La empresa para la que trabajo almacena casi todo en Subversion y usa svn:needs-lock para todos los archivos no fusionables.

No estoy de acuerdo con "los bloqueos son solo un método de comunicación". Son un método mucho más efectivo que las notificaciones push como el teléfono o el correo electrónico. Los bloqueos de Subversion son autodocumentados (quién tiene el bloqueo). 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 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 en contra de los principios de DVCS, es el único método factible para archivos no fusionables. Siempre que DVCS no tenga una función de bloqueo 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 formatos de archivo binarios, pero ese es un objetivo a largo plazo y continuo que nunca se "terminará".

Aquí hay una lectura interesante sobre el tema.