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:
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
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.
Comme 1, mais nous piratons une
git lock
commande 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 lock
s'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.