Workflow: Verwenden von binären Dokumentformaten in Git ohne Sperren (Umstieg von Subversion)

Wir sind eine Softwareberatung mit einer Vielzahl von Projekten für verschiedene Kunden. Wir verwenden traditionell Subversion, erwägen jedoch derzeit den Umstieg auf Git.

Ein erheblicher Teil der von uns erstellten Dokumente wird an unsere Kunden weitergegeben (Anforderungen, globale Designs, Testspezifikationen usw.), und wir verwenden MS Office, um diese zu erstellen. In Subversion könnten wir die Funktion "Sperren" verwenden, um sicherzustellen, dass niemand dasselbe Dokument zur gleichen Zeit bearbeitet. In Git ist dies nicht möglich, da git aufgrund seiner Verteilung keine Sperren hat.

Schlösser sind eigentlich kaum mehr als ein Kommunikationsmechanismus, aber sie sind sehr effektiv.

Derzeit befinden sich unser Code und kundenbezogene Dokumente in der Regel in verschiedenen Unterordnern eines anderen SVN-Repositorys. Was würden Sie empfehlen, wenn Sie zu git wechseln? Ich sehe eine Reihe von Optionen:

1. Wir verschieben die SVN-Repositorys 1-zu-1 nach Git. Anstatt Sperren für die Office-Dateien zu verwenden, tun wir, was die Git-Leute vorschlagen, und versuchen irgendwie, unseren Workflow zu ändern, um dies zu beheben. Dies könnte in einer Verzweigung bei jeder Dokumentbearbeitung funktionieren und diese über die Überprüfung zusammenführen. Dieser Ansatz bricht z. B. Excel-Tabellen ab, die Projektverwaltungsinformationen enthalten. Sie können von Teammitgliedern problemlos bearbeitet werden (und wir empfehlen dies zu tun), unterliegen jedoch keinem formellen Überprüfungsprozess

2. Wir verwenden git für Code und svn für Dokumente und Projektmanagement. Dies hat den Nachteil, dass bestimmte mehr gestalterische Dokumente nicht in der Nähe des angegebenen Codes sind, was die Wahrscheinlichkeit erhöht, dass Benutzer vergessen, sie zu aktualisieren. Darüber hinaus muss jeder zwei Werkzeugsätze verwenden und verstehen. Das heißt, vielleicht ist dies eine großartige Gelegenheit, auf textbasierte Dokumententools (Latex, Markdown, HTML usw.) für nicht kundenorientierte Designdokumente umzusteigen.

3. Wie 1, aber wir hacken einen git lockBefehl, der das tut, was svn lock für uns tut (schalten Sie das Nur-Lese-Flag entsprechend um und synchronisieren Sie mit einem Server auf irgendeine Weise).

Ich kaufe nicht das Argument, dass Sperren in einem DVCS nicht funktionieren, weil das System sogar funktionieren sollte, wenn Sie vollständig offline sind. Svn-Sperren können ebenfalls überschrieben werden. Sie sind ein Kommunikationsmechanismus . Ohne irgendeine Art von Netzwerkverbindung wird Ihr Computer nicht viel kommunizieren.

Wir können nicht der einzige Shop sein, der sehr zufrieden damit ist, wie es svn lockin unseren Workflow passt, oder?

Irgendwelche Ideen oder Tipps?

Ich habe /programming/119444/locking-binary-files-using-git-version-control-system gefunden, aber die Diskussion ist eher technisch. Ich suche nach Möglichkeiten, um das praktische Problem zu lösen oder zu vermeiden, dass zwei Teammitglieder gleichzeitig dieselbe Binärdatei bearbeiten.

Ich würde Ihnen aus zwei Gründen raten, bei SVN zu bleiben, um die MS Office-Dokumente zu erhalten:

1. Es ist schon da und es ist (meiner Meinung nach) besser für die Aufbewahrung von Office-Dokumenten (siehe hier ). Hat viel mehr Tools von Drittanbietern, um dies zu tun.
2. Die Sperre kann zwar in Git erreicht werden, ist jedoch nicht "die Art und Weise, wie Git Dinge tut". Wenn Sie diese Funktionen benötigen, halten Sie sich an das Tool, mit dem Sie die beste Lösung finden.

Es gibt ein Sprichwort, das ich mag, das so etwas sagt: "Wenn du einen Hammer hältst, sieht alles aus wie ein Nagel". Nur weil Sie zu Git wechseln, um Ihren Code zu speichern, bedeutet dies nicht, dass Sie ihn zum Speichern Ihrer Dokumente verwenden sollten.

Die Codeversionskontrolle ist nicht das beste Tool für die Bearbeitung von Office-Dateien, da es sich um Binärdateien handelt und diese Tools für die Bearbeitung auf Dateiebene geeignet sind.

Verwenden Sie ein Collaboration-Tool wie MediaWiki (kostenlos) oder Atlassian Confluence (kostenpflichtig), aus dem Sie problemlos Word-Dokumente extrahieren können. Oder verwenden Sie LaTex, um die Office-Dateien zu generieren.

Lass mich erweitern ...

Wenn Sie zusammenarbeiten müssen, müssen Sie ein Modell übernehmen, das die Änderungen (z. B. ein Wort geändert, umformuliert oder nur eine Schriftart geändert) an einer Einheit, z. B. einer Datei, hervorhebt.

SVN und Git sind, auch wenn sie für Code gedacht sind, einfache Tools, die ihre Dateien nach Textinhalten vergleichen. Das Problem ist jedoch, dass sie nur mit Textdateien arbeiten können, da sie sich nicht um die Art / den Inhalt der Datei kümmern, um ein Modell mit allgemeinen Änderungen zu extrahieren.

Ein klares Beispiel ist eine Bilddatei . Obwohl TortoiseMerge ein Tool ist, das SVN-Benutzern hilft, indem es die Bilder auf ihre tatsächlichen Änderungen hin vergleicht, wird VCSes normalerweise von Inhalts- Patches über die Dateien ausgeführt. Lassen Sie mich erklären. Ein Tool wie TortoiseMerge kann Ihnen mitteilen, dass sich eine neue Version einer Bilddatei nur um wenige Pixel oder die Helligkeit ändert, wenn eine komplexere HSV-Analyse der beiden Dateien implementiert wird. Sie können ein Wasserzeichen oder die Farbe ändern Ebenen, ein Werkzeug hinzufügen , die Bilddateien vergleicht werden markieren Sie die Unterschiede , wenn es gut Vergleichsalgorithmus implementiert. Aber um die neue Datei in Ihrem Client zu überprüfen, müssenein Delta erzeugen. Ein Delta ist eine Reihe von Zeilen, die entfernt und der Datei hinzugefügt werden. Binär - Dateien haben keine Zeilenumbrüche , wenn sie nicht passieren haben , \r\nin deren Nutzlast oder ähnlichen, und in einem Dreieck , wenn Sie ein einzelnes Zeichen ändern Sie eine ganze Zeile ersetzen.

Also hier ist das Problem. Binärdateien eignen sich nicht für die Versionskontrolle, da Sie möglicherweise bei jeder Revision die gesamte Datei ersetzen. Überlegen Sie, wann Sie Office-Dateien mit MS Office schreiben und welche Änderungen Ihr Mitarbeiter mit OpenOffice vornimmt. Wenn sie sogar eine geringfügig andere Version des Komprimierungsalgorithmus von OpenXML-Dateien implementieren, werden Sie völlig andere Dateien erhalten, selbst wenn Sie ein einzelnes Komma im Dokument geändert haben.

Collaboration-Software rendert Dokumente intern in einem textbasierten Format, da Text für Ihr Unternehmen wirklich von Bedeutung ist und die Unterschiede berechnen oder Konflikte behandeln kann. LaTeX oder Markdown , wenn Sie so wollen, ist eine Möglichkeit , ein Dokument als speichern Textdatei mit erweiterte Markup, also nicht wie der klassischen TXT - Datei , die keine Schrift / Formatierung Kontrolle hat.

Aber offensichtlich möchten Ihre Kunden Markdown-Dateien nicht öffnen, oder? Ok, Sie können einfach, und ich meine wirklich einfach, jede Software verwenden, nach der ich momentan zu faul bin, um zu googeln, um ein Quelldokument in PDF, Word oder was auch immer zu konvertieren .

Zusammenfassend

Wenn Sie Textdateien in Ihre Quellcodeverwaltung einchecken, haben Sie eine bessere Kontrolle über den Dateiversionsverlauf und können Konflikte problemlos verwalten, insbesondere ohne die Verwendung von VCS-Sperren.

Bevor Sie ein Dokument offiziell freigeben, benötigen Sie eine Routine, um das Quelltextdokument in eine Office-Datei zu exportieren

Die Trennung der beiden Schritte macht die Menschen auf Kosten einer Lernkurve glücklich.

Sie können git für diese Dokumente verwenden, ohne Sperren hinzuzufügen. Wählen Sie einen Git-Workflow, der die Weiterleitung an den Master-Zweig blockiert, wenn dieser nicht auf dem Master-Zweig liegt. (Es stehen mehrere Workflows zur Auswahl.) Dadurch wird verhindert, dass die Änderungen an binären Dokumentdateien gegenseitig überschrieben werden. Angenommen, zwei Personen ändern dasselbe Binärdokument. Der erste, der es an den Master schiebt, erhält seine Änderungen. Der zweite wird blockiert, weil sich seine Kopie hinter dem Master-Zweig befindet. Sie müssen zuerst synchronisieren. Die zweite Person synchronisiert also. Es wird ein Zusammenführungskonflikt für das Binärdokument angezeigt. Diese Person speichert ihre Version irgendwo und löst den Konflikt, indem sie die Version vom Master übernimmt (die von der ersten Person gepusht wurde). Zu diesem Zeitpunkt sind die Dateien der zweiten Person mit der Hauptniederlassung auf dem neuesten Stand. Sie führen ihre Änderungen zum neuesten Binärdokument (von Hand) zusammen, das dann sowohl die Änderungen der ersten als auch der zweiten Person enthält. Dann wird die neue Version zum Master verschoben und wird zum neuen Master-Zweig. Das Zusammenführen ist ein Schmerz, aber es passiert nur, wenn es einen Konflikt gibt. Außerdem gehen Änderungen nicht verloren oder werden überschrieben. Die Konflikte werden erkannt und Benutzer können sie sauber lösen.

Stellen Sie Ihre ersten 2 Lösungen zusammen und Sie brauchen keine dritte.

Wenn Sie Ihre Tabellenkalkulationen als CSVs auf der Festplatte speichern, werden sie von Excel weiterhin bearbeitet und von git gerne für Sie zusammengeführt.

Ebenso können Sie Ihre Dateien in Word öffnen, bearbeiten und speichern, wenn es sich um HTML- oder RTF-Dateien handelt. Word wird natürlich mehr aufblähen als nützlichen Text, aber es ist immer noch nur Text, den git gerne für Sie zusammenführt.

Zugegeben, bei diesen Lösungen wird davon ausgegangen, dass Sie keine MS-spezifischen Funktionen verwenden oder von diesen abweichen, was eigentlich nur ein Problem auf der Excel-Seite sein kann.

Es sei denn, Sie benötigen natürlich auch die Installation von Word auf einem System, um Ihre Dokumentation lesen zu können, was für mich selbst eine schreckliche Aussicht ist ...