Bloquear archivos binarios usando el sistema de control de versiones git

76

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.

Mario
fuente

Respuestas:

9

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.

osowskit
fuente
74

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.

Craig McQueen
fuente
9
Exactamente correcto. Un DVCS no está diseñado para ser controlado de forma centralizada. Sin embargo, podría ser factible construir un sistema controlado centralmente sobre un DVCS, lo que le brinda la potencia que la mayoría de los DVCS pueden proporcionar junto con el control central necesario en algunas situaciones.
Michael Johnson
Me doy cuenta de que esta pregunta avanza un poco, pero votar a favor como bloqueo fundamentalmente no tiene sentido bajo un DVCS. En su lugar, debería mirar algo como el flujo de trabajo 'Dictador y tenientes' git-scm.com/book/en/Distributed-Git-Distributed-Workflows
Aaron Newton
10

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.

Greg Hewgill
fuente
7
El mayor problema que veo es que git está totalmente diseñado para funcionar sin conexión. Aunque, como usted dice, puede usar scripts personalizados para implementar esto. Más allá de eso, me sentiría tentado a tener una rama de 'bloqueo' que se empuja y se tira de un control remoto. Todo lo que tiene es la mesa de bloqueo, que reemplaza al servidor de bloqueo.
Michael Johnson
1
@MichaelJohnson: También podría tener archivos .lock- <filename> en su rama principal. De esa manera, podría editar y desbloquear con una confirmación.
thejh
10

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.

Michael Johnson
fuente
104
Cualquier sistema de control de fuente es una mejor forma de comunicarse entre desarrolladores, porque está estructurado. El correo electrónico, el chat o el teléfono son peores porque no están estructurados. Entonces, cuando la gente dice que recurrirá a la comunicación por correo electrónico, chat o teléfono en lugar de usar scm, está mal. Mantener el código fuente y organizar la comunicación entre desarrolladores son 2 partes de cualquier SCM y git resuelve solo una parte cuando svn resuelve ambas.
alpav
7
El punto importante en mi mente es que un archivo bloqueado es de solo lectura en el disco y un archivo desbloqueado es RW. Esto significa que cuando alguien intenta editar un archivo bloqueado, su editor al menos le advertirá que el archivo es RO. En este punto se les pide que se comuniquen con quien haya bloqueado el archivo, para saber si sus cambios son redundantes, complementarios o incompatibles. Sin el VCS que cambia los permisos de archivo, no se solicita automáticamente al usuario que se comunique, y se deja en manos de su memoria falible y sus procedimientos.
KeyserSoze
53
La respuesta típica de git de "es un problema de comunicación, por lo que no tiene nada que ver con git" no se da cuenta de que "bloquear" es la comunicación efectiva de la intención de ser la única persona que trabaja en un archivo en un momento dado, probablemente porque es un archivo binario complejo que es muy difícil (imposible) de fusionar. Este es un requisito perfectamente válido y razonable en un gran equipo que trabaja con activos binarios. Al menos, sería muy útil poder bloquear un archivo en una rama con nombre. Este mensaje podría propagarse hasta el origen, el origen del origen, etc ...
Matt Connolly
21
-1 Esto no responde a la pregunta. La idea (implícita) en la pregunta es bloquear archivos para que otros sepan que está trabajando en un archivo antes de editarlo . Lo que describe es la resolución de conflictos estándar de git, que, aunque es muy útil, solo funciona después de que ha ocurrido el conflicto.
sleske
6
Entonces ... en un proyecto DVCS con 100 usuarios, la mayoría de los cuales no necesariamente "trabajo" con, ¿a quién le envío un correo electrónico cuando quiero acceso exclusivo a un archivo binario?
iheanyi
8

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.

Michael Johnson
fuente
2
La tecnología de un microondas no fue diseñada para calentar alimentos. ¿Me estás diciendo que, dado que git no fue diseñado originalmente para mi flujo de trabajo (y el flujo de trabajo de muchas personas), no debería usar git como DVCS? Te das cuenta de que la "solicitud de extracción" era crear niveles de desarrolladores que tenían diferentes niveles de autoridad / confianza en un proyecto. Para muchos de nosotros, trabajamos en proyectos en los que la mayoría de los ingenieros tienen la misma autoridad, hay relativamente pocos ingenieros por lo que el trabajo que hace cada persona es fundamental para el conjunto y no se puede dejar pendiente indefinidamente.
iheanyi
@iheanyi Un flujo de trabajo de solicitud de extracción funciona bien en el tipo de equipo que describe (por lo general, cualquier desarrollador puede fusionar la solicitud de extracción de otra persona).
Marnen Laibow-Koser
@ MarnenLaibow-Koser para nada. Lo que ha descrito invierte el flujo de trabajo. Ahora he fusionado los cambios de otra persona en lugar de que todos sean responsables de su propia fusión.
iheanyi
@iheanyi Eso es un beneficio. La idea es que nadie fusione sus propios cambios en maestro, para asegurarse de que alguien más los conozca y los apruebe. Y no invierte el flujo de trabajo: todavía está fusionando las solicitudes de extracción en el maestro, no en su propia rama. • Pero de todos modos, tampoco es necesario hacer eso para trabajar con Git. Absolutamente podría hacer un flujo de trabajo de rama de funciones en Git donde todos fusionen sus propios cambios y, por lo tanto, no haya solicitudes de extracción. No lo recomendaría, pero Git lo admite perfectamente.
Marnen Laibow-Koser
1
@ MarnenLaibow-Koser beneficia a algunos, no a otros. Empiezo a repetirme.
iheanyi
5

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.

Khoth
fuente
5

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.

Mario
fuente
5

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.

Jörg W Mittag
fuente
6
Pensaba que hablaba en serio hasta que leí "ASCII-Art for Visio": / (Tal vez lo fuera. ¿Cuál es la herramienta que usa para reemplazar Visio que no sea el viejo Vi?)
kizzx2
9
@ kizzx2: la herramienta principal que utilizo es un buen lenguaje de programación que es lo suficientemente legible como para no necesitar diagramas elaborados para entender que WTF está sucediendo. Más importante aún, trato de escribir código legible. Un buen IDE que puede inferir diagramas del código, en lugar de tener que mantenerlos a mano por separado. Para diagramas UML simples, puedo usar algo como yUML que admite diagramas de casos de uso, actividades y clases. Para gráficos simples, utilizo Diagrammr, que crea gráficos a partir de oraciones simples, y GraphViz para gráficos complejos.
Jörg W Mittag
1
¡Diagrammr parece realmente interesante! ¡Gracias!
kizzx2
1
En realidad, reemplazar al formato de texto no resuelve el problema. Algunos archivos binarios (como el mapa de bits puro) se pueden combinar sin problemas. El punto es la estructura interna y la dependencia. Si tiene algún archivo XML que depende del enlace para los otros nodos internos y necesita integridad en ese enlace, no se puede fusionar. Por lo general, los formatos de datos más complejos utilizan este tipo de enlace interno como una base de datos de gráficos.
eonil
El equivalente de código abierto de yUML es Plant UML
Mystic
3

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.

Dan
fuente
1

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.

JesperE
fuente
1

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


fuente
¿Simplemente abrir un archivo cambiará algunos bits arbitrarios? ¡Eso suena como un error grave!
Stein G. Strindhaug
1

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.

Antonio Bardazzi
fuente
¿Facilita la fusión sin problemas de archivos de Office y OpenDocument?
Craig McQueen
1
Hmm, ¿qué pasa si estoy trabajando con algún otro archivo binario, Word, Excel, video, algún archivo de imagen?
iheanyi
0

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.

Hernan Rajchert
fuente
3
Creo que la mejor solución a largo plazo sería utilizar mejores herramientas. Una buena wiki sería de gran ayuda, o simplemente usar algo que no almacene binarios (HTML, TeX, etc.). El bloqueo es bueno, pero parece que la mayoría de la gente solo quiere usar el bloqueo porque las diferencias binarias son difíciles de manejar, pero para la mayoría de estos usos no hay razón para almacenar binarios. Mantienes el código fuente en git, no dlls / sos y ejecutables, entonces, ¿por qué almacenar versiones compiladas de documentos?
semi
0

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.

alpav
fuente
2
Gran parte de git está diseñado específicamente para equipos, esa es un área (entre muchas otras) donde git está muy por delante de SVN. Bloquear no es tan fácil como SVN para este tipo de situación, sin embargo, hay características que ayudarían, como combinar controladores.
shmish111
@ shmish111: La comunicación de bloqueos entre desarrolladores es una parte esencial de un entorno de equipo, ¿por qué cree que "este tipo de situación" no necesita ser cubierto? Svn permite a los desarrolladores comunicar bloqueos / desbloqueos, Git no. Git debería haberlo hecho opcional, pero función disponible.
alpav
1
Como dije, git es más débil que SVN cuando se trata de bloquear. Solo me encontré con este requisito una vez y resultó que al final no teníamos que hacerlo. Sugeriría que a menudo (no siempre) cuando un archivo necesita bloquearse, es una buena indicación de que podría estar organizando mejor su proyecto. Git está diseñado específicamente para el trabajo en equipo, por lo que decir que no es para un entorno de equipo es una locura. Decir que los entornos de equipo están hechos para despojar a los desarrolladores de la seguridad laboral es increíblemente loco.
shmish111
@alpav “La comunicación de bloqueos entre desarrolladores es parte esencial de un entorno de equipo” Solo si los bloqueos son necesarios en primer lugar. En general, no lo son. (He trabajado sin bloquear durante 20 años bastante felizmente. No veo por qué lo querría.)
Marnen Laibow-Koser
0

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.

Shell remoto
fuente
5
Me interesaría escuchar esto explicado con más detalle.
Craig McQueen
0

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.

Stefan
fuente
-1

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.

Cherler Ton
fuente