Verrouillage des fichiers binaires à l'aide du système de contrôle de version git
Depuis un an et demi, je garde les yeux 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 en cas de risque de conflit de fichiers binaires.
Pour obtenir les effets du verrouillage, un référentiel "central" doit être identifié. Indépendamment de la nature distribuée de git, la plupart des entreprises disposeront d'un référentiel "central" 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 ne contient pas le contenu des fichiers.
Avez-vous de l'expérience avec les fichiers binaires et git 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 principal le verrouillage.
Git LFS 2.0 a ajouté le support pour le verrouillage de fichier.
Avec 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.
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.
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 central, 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 central, 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".
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:
- Avoir une façon de marquer un fichier comme "nécessite-verrouiller" (comme la propriété "svn: needs-lock").
- Lors du paiement, git marquerait un tel fichier comme étant en lecture seule.
- Une nouvelle commande
git-lockcontacterait un serveur de verrouillage centralisé s'exécutant quelque part pour demander l'autorisation de verrouiller. - Si le serveur de verrouillage accorde l'autorisation, marquez le fichier en lecture-écriture.
git-addinformerait le serveur de verrouillage du hachage de contenu du fichier verrouillé.- Le serveur de verrouillage surveillera l'apparition de ce hachage de contenu dans une validation sur le référentiel maître.
- Lorsque le hachage apparaît, libérez le verrou.
C'est une idée à moitié cuite et il y a des trous potentiels partout. Cela va également à l’encontre de l’esprit de git, mais cela peut certainement être utile dans certains contextes.
Au sein d'une organisation particulière, ce genre de choses pourrait peut-être être construit en utilisant une combinaison appropriée de wrappers de script et de hooks 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 au même moment. Ils ont chacun leur propre dépôt local, cloné à partir d’une télécommande centrale.
C'est en effet un problème potentiel. Alors, 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 (en partant de alice/update et y apportant ses modifications) ou (2) publier ses propres modifications dans bob/update. Encore une fois, il fait une annonce.
Maintenant, si Alice insiste plutôt sur master, Bob est confronté à un dilemme lorsqu'il tire master 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.
Puisque (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 manière 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 branche, puis de la fusionner dans la branche principale (ou selon la branche cible).
De la manière dont git est "destiné" à être utilisé, chaque développeur publie son propre référentiel public, qu’il demande aux autres utilisateurs d’extraire. J'ai constaté que les utilisateurs de Subversion avaient des problèmes avec ça. Par conséquent, nous poussons plutôt vers des branches 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 dépôt local pour l'utilisateur a:
feature1
feature2
Et pour l'obtenir sur le serveur central (Origin):
git Push Origin feature1:users/a/feature1
(ceci peut probablement être simplifié avec des changements 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 tous les nouveaux changements principaux et la branche de fonctionnalité) et met à jour le maître en fonction 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 modifie une ressource binaire, celle-ci est examinée avant d'être intégrée à la branche principale. Et il existe une délimitation claire (basée sur le processus) quant au moment où quelque chose entre 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, j'ai défini religieusement la propriété svn:needs-lock sur tous les fichiers binaires et même les fichiers texte difficiles à modifier. Je (jamais} _ eu réellement des conflits.
Maintenant, à Git, je ne m'inquiète pas de ce genre de choses. Rappelez-vous: les verrous dans Subversion ne sont pas réellement des verrous obligatoires, ils sont simplement des outils de communication. Et devinez quoi: je n'ai pas besoin de Subversion pour communiquer, je peux très bien gérer avec E-Mail, Phone et IM.
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ΤΕΧ 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.
Il est intéressant 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 de manière indépendante, et un peu de communication peut aller très loin.
J'ai discuté de cette question sur les groupes de discussion git et je suis parvenu à la conclusion qu'il existe actuellement une non méthode convenue de 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 aussi en déléguant aux formats OpenOffice for OpenDocument.
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 les ouvriraient simplement en modifiant des bits arbitraires, considérés comme un nouveau fichier par n'importe quel 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 la 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 selon d'autres priorités (emplacement, clients, ...)
- Les outils sont également sélectionnés par d'autres cibles (compatibilité, prix, facilité d'utilisation par 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 correspondent pas à la philosophie de git (ce qui n’a jamais été fait 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.
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 crois me souvenir que quelqu'un a parlé (ou même implémenté) le support pour la fusion de documents OpenOffice dans git.
Ce n'est pas une solution mais plutôt un commentaire sur la raison pour laquelle des mécanismes de verrouillage sont nécessaires. Certains outils utilisés dans certains domaines utilisent des formats uniquement binaires qui sont essentiels à la mission et l'option "utiliser 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 pour 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 é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. Je l'ai vu et j'en ai marre d'un flot incessant d'e-mails de "je suis en train de l'éditer", "j'ai fini d'éditer" et j'ai vu les modifications perdues à 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 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 nécessite un environnement d'équipe (généralement pour débarrasser les développeurs de la sécurité de l'emploi), utilisez 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 de réaliser cette fonction en utilisant 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 indiquer au serveur auxiliaire les informations du casier et du fichier verrouillé.