Workflow: Utiliser des formats de documents binaires dans Git sans verrous (passer de subversion)

Nous sommes un cabinet de conseil en logiciels avec une multitude de projets pour différents clients. Nous utilisons traditionnellement Subversion, mais envisageons actuellement de passer à Git.

Une partie importante des documents que nous produisons est partagée avec nos clients (exigences, conceptions globales, spécifications de test, etc.), et nous utilisons MS Office pour les produire. Dans Subversion, nous pouvions utiliser sa fonction "Lock" pour nous assurer que personne n'éditait le même document en même temps. Dans Git, vous ne pouvez pas faire cela car, par sa nature distribuée, git n'a pas de verrous.

Les verrous ne sont en réalité guère plus qu'un mécanisme de communication, mais ils sont très efficaces.

Actuellement, notre code et nos documents destinés aux clients se trouvent généralement dans différents sous-dossiers d'un référentiel svn différent. Lorsque vous passez à git, que recommanderiez-vous que nous fassions? Je vois un ensemble d'options:

1. Nous déplaçons les dépôts svn vers git 1-on-1. Au lieu d'utiliser des verrous sur les fichiers Office, nous faisons ce que les gens de git suggèrent et essayons en quelque sorte de modifier notre flux de travail pour le corriger. Cela pourrait être de travailler dans une branche sur n'importe quelle modification de document et de la fusionner lors de la révision. Cette approche dépasse par exemple les feuilles Excel contenant des informations de gestion de projet; ils sont facilement édités par les membres de l'équipe (et nous vous encourageons à le faire), mais ne sont soumis à aucun processus d'examen officiel

2. Nous utilisons git pour le code et svn pour les documents et la gestion de projet. Cela présente l'inconvénient que certains documents plus design ne seront pas "à proximité" du code qu'il spécifie, ce qui augmente les chances que les gens oublient de les mettre à jour. De plus, tout le monde doit utiliser et comprendre deux ensembles d'outils. Cela dit, c'est peut-être une excellente occasion de passer à des outils de documentation textuels (latex, démarque, HTML, peu importe) pour les documents de conception non destinés au client.

3. Comme 1, mais nous piratons une git lockcommande qui fait ce que le verrouillage svn fait pour nous (basculer le drapeau en lecture seule de manière appropriée et synchroniser avec un serveur par certains moyens).

Je n'accepte pas l'argument selon lequel les verrous ne fonctionnent pas dans un DVCS, car le système devrait même fonctionner lorsque vous êtes entièrement hors ligne. Les verrous Svn peuvent également être remplacés; c'est un mécanisme de communication . Sans une sorte de connexion réseau, vous ne communiquerez pas beaucoup avec votre ordinateur.

Nous ne pouvons pas être le seul magasin à être très satisfait de la façon dont svn locks'intègre notre flux de travail, non?

Des idées ou des conseils?

J'ai trouvé /programming/119444/locking-binary-files-using-git-version-control-system mais la discussion est plutôt technique; je cherche des moyens de résoudre ou d'éviter le problème pratique de deux membres de l'équipe éditant le même fichier binaire en même temps.

Je vous conseille de rester avec SVN pour les documents MS Office pour deux raisons:

1. Il est déjà là et il est (à mon avis) préférable de conserver les documents Office (regardez ici ). A beaucoup plus d'outils tiers pour ce faire.
2. Le verrouillage, bien qu'il soit possible de le faire dans Git, n'est pas "le genre de façon de faire Git". Si vous avez besoin de ces fonctionnalités, restez avec l'outil qui vous donne la meilleure solution.

Il y a un dicton que j'aime qui dit quelque chose comme ceci: "Quand vous tenez un marteau, tout ressemble à un clou". Ce n'est pas parce que vous vous déplacez vers Git pour conserver votre code que vous devez l'utiliser pour conserver vos documents.

Le contrôle de version de code n'est pas le meilleur outil pour travailler sur des fichiers Office, car ils sont binaires et ces outils fonctionnent sur la modification au niveau du fichier.

Utilisez un outil de collaboration, comme MediaWiki (gratuit) ou Atlassian Confluence (payant), à partir duquel vous pouvez facilement extraire un document Word. Ou utilisez LaTex pour générer les fichiers Office.

Permettez-moi de développer ...

Si vous avez besoin de collaborer, vous devez adopter un modèle qui met en évidence les modifications (par exemple, a changé un mot, reformulé ou simplement changé une police) à une unité, par exemple un fichier.

SVN et Git, même si on pense au code, sont des outils de bas niveau qui comparent leurs fichiers par contenu textuel. Mais le problème est qu'ils ne peuvent travailler que sur des fichiers texte, car ils ne se soucient pas de la nature / du contenu du fichier pour extraire un modèle de modifications de haut niveau.

Un exemple clair est un fichier image . Bien que TortoiseMerge soit un outil qui aide les utilisateurs de SVN en comparant les images pour leurs vraies modifications, les VCSes normales sont exécutées par des correctifs de contenu sur les fichiers. Laissez-moi expliquer. Un outil tel que TortoiseMerge peut vous dire qu'une nouvelle version d'un fichier image n'est modifiée que de quelques pixels, ou la luminance si elle implémente une analyse HSV plus complexe des deux fichiers. Vous pouvez ajouter un filigrane ou modifier les niveaux de couleur, un outil qui compare les fichiers image vous mettra en évidence les différences s'il met en œuvre un bon algorithme de comparaison. Mais pour vérifier le nouveau fichier dans votre client doitproduire un delta. Un delta est un ensemble de lignes qui sont supprimées et des lignes qui sont ajoutées au fichier. Les fichiers binaires n'ont pas de sauts de ligne s'ils ne se trouvent pas avoir \r\n, ou similaire, dans leur charge utile, et dans un delta si vous changez un seul caractère, vous remplacez une ligne entière.

Voici donc le problème. Les fichiers binaires ne sont pas bons pour le contrôle de version car vous pourriez presque remplacer le fichier entier pour chaque révision. À considérer lorsque vous écrivez des fichiers Office à l'aide de MS Office et les modifications de votre collaborateur avec OpenOffice. S'ils implémentent même une version légèrement différente de l'algorithme de compression des fichiers OpenXML, vous vous retrouverez dans des fichiers complètement différents même si vous avez modifié une seule virgule dans le document.

Les logiciels de collaboration affichent les documents en interne dans un format texte , car le texte est vraiment significatif pour votre entreprise et peut calculer les différences ou gérer les conflits. LaTex, ou Markdown si vous le souhaitez, est un moyen de stocker un document sous forme de texte fichier avec un balisage avancé, donc pas comme le fichier TXT classique qui n'a aucun contrôle de police / formatage.

Mais évidemment, vos clients n'aimeront pas ouvrir les fichiers Markdown, n'est-ce pas? Ok, vous pouvez simplement, et je veux dire simplement, utiliser n'importe quel logiciel pour lequel je suis trop paresseux pour convertir un document source en PDF, Word ou autre.

Résumer

Si vous commencez à archiver des fichiers texte dans votre contrôle de source, vous contrôlez mieux l'historique des fichiers et pouvez facilement gérer les conflits, en particulier sans utiliser de verrous VCS.

Avant de partager un document officiellement, vous avez besoin d'une routine pour exporter le document texte source vers un fichier Office

Séparer les deux étapes rend les gens heureux au prix d'une courbe d'apprentissage.

Vous pouvez utiliser git pour ces documents sans ajouter de verrouillage. Choisissez un flux de travail git qui bloque les push vers la branche principale s'il n'est pas sur le maître. (Il existe plusieurs workflows parmi lesquels choisir.) Cela empêchera les utilisateurs d'écraser les modifications apportées aux fichiers de documents binaires. Supposons que deux personnes modifient le même document binaire. Le premier qui le pousse vers master obtient ses modifications. Le second sera bloqué car leur copie est derrière la branche master. Ils doivent d'abord se synchroniser. Donc la deuxième personne se synchronise. Il affichera un conflit de fusion pour le document binaire. Cette personne enregistre sa version quelque part et résout le conflit en prenant la version du maître (qui a été poussée par la première personne). À ce stade, les fichiers de la deuxième personne sont à jour avec la branche principale. Ils fusionnent dans leurs modifications vers le dernier document binaire (à la main), qui contiendra ensuite les modifications de la première personne et de la deuxième personne. Ensuite, la nouvelle version est poussée vers master et devient la nouvelle branche master. La fusion est pénible, mais elle ne se produit qu'en cas de conflit. De plus, les modifications ne sont ni perdues ni écrasées. Les conflits sont détectés et les utilisateurs peuvent les résoudre proprement.

Mettez vos 2 premières solutions ensemble et vous n'avez pas besoin d'une troisième.

Si vous enregistrez vos feuilles de calcul sur le disque au format CSV, Excel les éditera quand même et git se fera un plaisir de les fusionner pour vous.

De même, vous pouvez ouvrir, modifier et enregistrer vos fichiers dans Word s'ils sont HTML ou (Dieu nous aide) RTF. Word ajoutera bien sûr plus de ballonnement que de texte utile, mais ce n'est que du texte que git est heureux de fusionner pour vous.

Certes, ces solutions supposent que vous ne faites pas usage ou que vous pouvez vous éloigner des fonctionnalités spécifiques à MS, ce qui n'est vraiment qu'un problème du côté d'Excel.

À moins bien sûr que vous ayez également besoin que Word soit installé sur un système pour pouvoir lire votre documentation, ce qui est en soi une perspective terrifiante pour moi ...