Verrouillage des fichiers binaires à l'aide du système de contrôle de version git

https://stackoverflow.com/questions/119444

02-07-2019
|

Question

Depuis un an et demi, je garde un oeil sur la communauté des génies dans l’espoir de passer de SVN à autre chose. L'incapacité de verrouiller les fichiers binaires est un problème qui me retient. Au cours de l’année écoulée, je n’ai pas encore vu les développements sur ce sujet. Je comprends que le verrouillage des fichiers va à l’encontre des principes fondamentaux du contrôle de source distribuée, mais je ne vois pas comment une entreprise de développement Web peut tirer parti de git pour suivre les modifications du code source et des fichiers image lorsque des conflits de fichiers binaires risquent de se produire.

Pour obtenir les effets de verrouillage, un paramètre "central". le référentiel doit être identifié. Indépendamment de la nature distribuée de git, la plupart des entreprises auront un environnement "central". référentiel pour un projet logiciel. Nous devrions pouvoir marquer un fichier comme nécessitant un verrou du dépôt git qui le gouverne à une adresse spécifiée. C’est peut-être difficile parce que git suit le contenu des fichiers, pas les fichiers?

Avez-vous de l'expérience avec les fichiers git et binaires qui devraient être verrouillés avant d'être modifiés?

REMARQUE: il semble que le nouveau projet de contrôle de version distribué open source de Source Gear, Veracity, ait pour objectif de verrouiller.

La solution

Git LFS 2.0 ajoute la prise en charge du fichier. verrouillage.

Grâce à Git LFS 2.0.0, vous pouvez désormais verrouiller les fichiers sur lesquels vous travaillez, ce qui empêche les autres utilisateurs de le transmettre au serveur Git LFS jusqu'à ce que vous les déverrouilliez à nouveau.

Cela évitera les conflits de fusion ainsi que la perte de travail sur les fichiers non fusionnables au niveau du système de fichiers. Bien que cela puisse sembler contredire la nature distribuée et parallèle de Git, le verrouillage de fichiers est une partie importante de nombreux flux de travail de développement logiciel, en particulier pour les grandes équipes travaillant avec des actifs binaires.

Autres conseils

Subversion a des verrous, et ils ne sont pas que des conseils. Ils peuvent être appliqués à l'aide de l'attribut svn: needs-lock (mais peuvent également être délibérément rompus si nécessaire). C'est la bonne solution pour gérer les fichiers non fusionnables. La société pour laquelle je travaille stocke à peu près tout dans Subversion et utilise svn: needs-lock pour tous les fichiers non fusionnables.

Je ne suis pas d'accord avec "les verrous ne sont qu'une méthode de communication". Ils constituent une méthode beaucoup plus efficace que les notifications push, telles que le téléphone ou le courrier électronique. Les verrous Subversion sont auto-documentés (qui a le verrou). D'autre part, si vous devez communiquer par d'autres canaux de notification push traditionnels, tels que le courrier électronique, à qui envoyez-vous la notification? Vous ne savez pas à l'avance qui peut vouloir éditer le fichier, en particulier sur les projets open-source, à moins de disposer d'une liste complète de toute votre équipe de développement. Donc, ces méthodes de communication traditionnelles ne sont pas aussi efficaces.

Un serveur de verrouillage centralisé, contrairement aux principes de DVCS, est la seule méthode possible pour les fichiers non fusionnables. Tant que DVCS n’aura pas de fonction de verrouillage centralisé, je pense que cela permettra à la société pour laquelle je travaille d’utiliser Subversion.

La meilleure solution serait de créer un outil de fusion pour tous vos formats de fichiers binaires, mais c’est un objectif permanent et à long terme qui ne sera jamais "fini".

Voici une lecture intéressante sur le sujet.

Je conviens que le verrouillage des fichiers binaires est une fonctionnalité nécessaire dans certains environnements. Je viens juste de penser à la façon de mettre en œuvre cela, cependant:

Vous pouvez marquer un fichier comme suit: "need-lock". (comme la propriété "svn: needs-lock").
Lors du paiement, git marquerait un tel fichier comme étant en lecture seule.
Une nouvelle commande git-lock contacterait un serveur de verrouillage central exécuté quelque part pour demander l'autorisation de verrouillage.
Si le serveur de verrouillage accorde l'autorisation, marquez le fichier en lecture-écriture.
git-add informerait le serveur de verrouillage du hachage de contenu du fichier verrouillé.
Le serveur de verrouillage vérifiera que ce hachage de contenu apparaît dans une validation sur le référentiel maître.
Lorsque le hachage apparaît, libérez le verrou.

C’est vraiment une idée à moitié cuite et il y a des trous potentiels partout. Cela va également à l’encontre de l’esprit de git, mais il peut certainement être utile dans certains contextes.

Au sein d'une organisation particulière, ce type de solution pourrait peut-être être construit à l'aide d'une combinaison appropriée de wrappers de script et de crochets de validation.

En réponse aux préoccupations supplémentaires de Mario concernant les changements qui se produisent à plusieurs endroits sur les fichiers binaires. Le scénario est donc Alice et Bob apportent tous deux des modifications à la même ressource binaire en même temps. Ils ont chacun leur propre dépôt local, cloné à partir d’une télécommande centrale.

C’est effectivement un problème potentiel. Donc, Alice termine en premier et passe à la branche centrale alice / update . Normalement, lorsque cela se produirait, Alice ferait une annonce pour que le document soit examiné. Bob le voit et le passe en revue. Il peut soit (1) incorporer lui-même ces modifications dans sa version (à partir de alice / update et y apporter ses modifications) ou (2) publier ses propres modifications dans bob / update . Encore une fois, il fait une annonce.

Désormais, si Alice insiste sur maître , Bob est confronté à un dilemme lorsqu'il extrait maître et tente de se fondre dans sa branche locale. Ses conflits avec Alice. Mais encore une fois, la même procédure peut s’appliquer, mais sur des branches différentes. Et même si Bob ignore tous les avertissements et s’engage sur celui d’Alice, il est toujours possible de retirer l’engagement d’Alice pour régler le problème. Cela devient simplement un problème de communication.

Depuis (autant que je sache), les verrous Subversion ne sont qu’indicatifs, un courrier électronique ou un message instantané pourrait avoir le même objectif. Mais même si vous ne le faites pas, Git vous permet de le réparer.

Non, il n'y a pas de mécanisme de verrouillage en soi. Mais un mécanisme de verrouillage tend à se substituer à une bonne communication. Je crois que c’est la raison pour laquelle les développeurs Git n’ont pas ajouté de mécanisme de verrouillage.

Nous venons tout juste de commencer à utiliser Git (utilisé précédemment par Subversion) et j'ai trouvé un changement dans le flux de travail qui pourrait vous aider à résoudre votre problème, sans avoir besoin de verrous. Il tire parti de la façon dont git est conçu et de la simplicité de ses branches.

En gros, il s’agit de passer à une branche non maîtresse, d’examiner cette dernière, puis de la fusionner dans la branche principale (ou selon la branche cible).

La manière dont git est "prévu" pour être utilisés, chaque développeur publie son propre référentiel public, qu’il demande aux autres utilisateurs d’utiliser. J'ai constaté que les utilisateurs de Subversion avaient des problèmes avec ça. Ainsi, au lieu de cela, nous poussons vers des arbres de branche dans le référentiel central, chaque utilisateur ayant son propre arbre de branche. Par exemple, une hiérarchie comme celle-ci pourrait fonctionner:

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

N'hésitez pas à utiliser votre propre structure. Remarque: je montre également des branches de sujet, un autre langage courant de git.

Puis dans un référentiel local pour l'utilisateur a:

feature1
feature2

Et pour le transférer sur le serveur central (origine):

git push origin feature1:users/a/feature1

(cela peut probablement être simplifié avec des modifications de configuration)

Quoi qu’il en soit, une fois la fonctionnalité1 vérifiée, quel que soit le responsable (dans notre cas, c’est le développeur de la fonctionnalité, vous pouvez avoir un seul utilisateur responsable des fusions vers le maître):

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

L'extraction effectue une extraction (en extrayant les nouveaux changements de maître et de la branche de fonctionnalité) et met à jour le maître vers celui du référentiel central. Si l’utilisateur a effectué son travail et suivi correctement le maître, la fusion ne devrait poser aucun problème.

Tout cela signifie que, même si un utilisateur ou une équipe distante apporte une modification à une ressource binaire, celle-ci est examinée avant son intégration dans la branche principale. Et il existe une délimitation claire (basée sur le processus) quant au moment où quelque chose passe dans la branche principale.

Vous pouvez également appliquer par programmation des aspects de cela à l'aide de git hook, mais encore une fois, je n'ai pas encore travaillé avec ceux-ci, je ne peux donc pas en parler.

Lorsque j'utilisais Subversion, je définissais religieusement la propriété svn: needs-lock sur tous les fichiers binaires et même les fichiers texte difficiles à modifier. Je n'ai jamais expérimenté de conflit.

Maintenant, à Git, je ne m'inquiète pas de ce genre de choses. Rappelez-vous: les verrous dans Subversion ne sont pas des verrous obligatoires, ils ne sont que des outils de communication. Et devinez quoi: je n’ai pas besoin de Subversion pour communiquer, je peux très bien me gérer avec la messagerie électronique, le téléphone et la messagerie instantanée.

Une autre chose que j’ai faite est de remplacer de nombreux formats binaires par des formats de texte brut. J'utilise reStructuredText ou La & # 932; _{& # 917;} & # 935; au lieu de Word, CSV au lieu d’Excel, ASCII-Art au lieu de Visio, YAML au lieu de bases de données, SVG au lieu de OO Draw, abc au lieu de MIDI, etc.

Cela vaut la peine d'examiner votre flux de travail actuel pour voir si le verrouillage des images est vraiment nécessaire. Il est relativement inhabituel pour deux personnes de modifier une image indépendamment, et un peu de communication peut faire beaucoup de choses.

J'ai discuté de cette question dans le cadre de groupes de discussion git et j'ai conclu qu'à l'heure actuelle, il n'y avait pas de méthode convenue pour le verrouillage centralisé des fichiers pour git.

TortoiseGit prend en charge le flux de travail git complet pour les documents Office qui délèguent diff à Office. Cela fonctionne également en déléguant aux formats OpenOffice for OpenDocument.

Je ne m'attendrais pas à ce que le verrouillage de fichier devienne jamais une fonctionnalité de git. Quel type de fichier binaire vous intéresse principalement? Êtes-vous réellement intéressé par le verrouillage des fichiers ou simplement par la prévention des conflits causés par l'impossibilité de les fusionner?

Je semble me souvenir que quelqu'un a parlé (ou même implémenté) la prise en charge de la fusion de documents OpenOffice dans git.

Qu'en est-il des fichiers CAD? Si les fichiers ne sont pas verrouillés, pour rester également en lecture seule, la plupart des programmes CAO ne feraient que leur ouvrir des bits de changement arbitraires, considérés comme un nouveau fichier par tout vcs. Donc, à mon avis, le verrouillage est un moyen idéal pour communiquer votre intention de modifier un fichier particalur. En outre, cela empêche certains logiciels d’obtenir un accès en écriture en premier lieu. Cela permet de mettre à jour les fichiers locaux sans qu'il soit nécessaire de fermer le logiciel ou du moins tous les fichiers.

Il suffit de placer un fichier texte au format cc avec le fichier que vous souhaitez verrouiller, puis de le rejeter par le crochet de mise à jour.

Il est peut-être vrai que la réorganisation d'un projet peut aider à éviter les verrous, mais:

Les équipes sont également organisées en fonction d'autres priorités (emplacement, clients, ...)
Les outils sont également sélectionnés par d'autres cibles (compatibilité, prix, facilité d'utilisation pour la plupart des employés)
Certains outils (et donc leurs fichiers binaires) ne peuvent pas être évités, car il n’ya tout simplement aucun remplaçant capable de faire le même travail, répondant aux mêmes besoins de la société pour le même prix.

Demander à une société entière de réorganiser son flux de travail et de remplacer tous ses outils produisant des fichiers binaires, pour pouvoir uniquement travailler avec git, en raison du manque de verrous, semble tout à fait inefficace.

Les verrous ne cadrent pas avec la philosophie de git (ce qui n’a jamais été conçu pour les binaires), mais il existe des situations non négligeables où les verrous sont le moyen le plus efficace de résoudre un tel problème.

Ce n’est pas une solution, mais plutôt un commentaire expliquant pourquoi des mécanismes de verrouillage sont nécessaires. Certains outils utilisés dans certains domaines utilisent des formats uniquement binaires qui sont absolument essentiels à la mission et qui utilisent des outils "meilleurs / différents". n'est tout simplement pas une option. Il n'y a pas d'autres outils viables. Ceux que je connais bien ne seraient vraiment pas candidats à la fusion, même si vous stockiez les mêmes informations dans un format ascii. Une objection que j'ai entendue est que vous voulez pouvoir travailler en mode hors connexion. De toute façon, l'outil auquel je pense ne fonctionne vraiment pas hors ligne, car il doit extraire des licences. Par conséquent, si j'ai des données sur un ordinateur portable, ce n'est pas comme si je pouvais utiliser l'outil quand même dans un train. Cela dit, ce que git fournit si ma connexion est lente, je peux obtenir des licences et effectuer des modifications, mais disposer de la copie locale rapide permettant d’examiner différentes versions. C’est une bonne chose que le DVCS vous offre même dans ce cas.

Un point de vue est que git n’est tout simplement pas l’outil à utiliser mais qu’il est agréable pour tous les fichiers texte qui sont également gérés avec lui et qu’il est agaçant d’avoir besoin d’outils de contrôle de version différents pour différents fichiers.

L’approche de type conseil-verrouillage-par-courrier pue vraiment. J'ai vu cela et j'en ai marre d'un flot incessant d'e-mails de "Je suis en train de le modifier". "J'ai terminé la rédaction" et vu les changements perdus à cause de cela. Le cas particulier auquel je pense est celui où une collection de fichiers ASCII plus petits aurait été beaucoup plus agréable, mais c’est un aparté.

Je ne suggère pas d'utiliser git dans mon entreprise pour le même problème. Nous utilisons EA pour toutes nos conceptions et Microsoft Word pour la documentation. Nous ne savons pas à l'avance qui peut éditer un fichier particulier. Le verrouillage exclusif est donc notre seule option.

git fonctionnera très bien dans un environnement sans équipe où chaque développeur est seul responsable d'un morceau de code ou d'un fichier, car dans ce cas, la communication à propos des verrous n'est pas nécessaire.

Si votre organisation a besoin d'un environnement d'équipe (généralement pour débarrasser les développeurs de la sécurité de l'emploi), utilisez svn svn, git n'est pas pour vous. Svn fournit à la fois le contrôle de source et la communication entre développeurs sur les verrous.

Git ne fournit aucune commande pour verrouiller les fichiers, mais j’ai trouvé un moyen d’exécuter cette fonction à l’aide de git hooks. Un serveur auxiliaire est nécessaire pour stocker les informations de verrouillage. Nous pouvons utiliser un hook de pré-validation pour vérifier si l'un des fichiers validés est verrouillé. Et si quelqu'un verrouille un fichier, un programme doit informer le serveur auxiliaire des informations relatives au casier et au fichier verrouillé.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow