Sperren von Binärdateien mit dem Git-Versionskontrollsystem

Seit anderthalb Jahren behalte ich die Git-Community im Auge, in der Hoffnung, den Wechsel von SVN zu schaffen. Ein besonderes Problem, das mich zurückhält, ist die Unfähigkeit, Binärdateien zu sperren. Im Laufe des vergangenen Jahres habe ich noch keine Entwicklungen zu diesem Thema gesehen. Ich verstehe, dass das Sperren von Dateien gegen die Grundprinzipien der verteilten Quellcodeverwaltung verstößt, aber ich sehe nicht, wie ein Webentwicklungsunternehmen git nutzen kann, um Änderungen an Quellcode und Bilddateien zu verfolgen, wenn die Gefahr von Konflikten mit Binärdateien besteht.

Um die Auswirkungen der Sperrung zu erzielen, muss ein "zentrales" Repository identifiziert werden. Unabhängig von der Verteilung von Git verfügen die meisten Unternehmen über ein "zentrales" Repository für ein Softwareprojekt. Wir sollten in der Lage sein, eine Datei so zu markieren, dass eine Sperre des maßgeblichen Git-Repositorys an einer bestimmten Adresse erforderlich ist. Vielleicht wird dies erschwert, weil Git Dateiinhalte verfolgt, keine Dateien?

Hat jemand von euch Erfahrung im Umgang mit Git- und Binärdateien, die vor der Änderung gesperrt werden sollten?

HINWEIS: Es sieht so aus, als ob das neue Open Source-Projekt zur verteilten Versionskontrolle von Source Gear, Veracity, das Sperren als eines seiner Ziele hat.

Git LFS 2.0 bietet Unterstützung für das Sperren von Dateien.

Mit Git LFS 2.0.0 können Sie jetzt Dateien sperren, an denen Sie gerade arbeiten, und verhindern, dass andere Benutzer auf den Git LFS-Server zugreifen, bis Sie die Dateien erneut entsperren.

Dies verhindert Zusammenführungskonflikte sowie Arbeitsausfälle bei nicht zusammenführbaren Dateien auf Dateisystemebene. Während dies der verteilten und parallelen Natur von Git zu widersprechen scheint, ist das Sperren von Dateien ein wichtiger Bestandteil vieler Softwareentwicklungs-Workflows - insbesondere für größere Teams, die mit binären Assets arbeiten.

Subversion hat Sperren und sie sind nicht nur beratend. Sie können mit dem svn:needs-lockAttribut erzwungen werden (können aber bei Bedarf auch absichtlich unterbrochen werden). Es ist die richtige Lösung für die Verwaltung nicht zusammenführbarer Dateien. Die Firma, für die ich arbeite, speichert fast alles in Subversion und verwendet sie svn:needs-lockfür alle nicht zusammenführbaren Dateien.

Ich bin nicht einverstanden mit "Schlösser sind nur eine Kommunikationsmethode". Sie sind eine viel effektivere Methode als Push-Benachrichtigungen wie Telefon oder E-Mail. Subversion-Sperren sind selbstdokumentierend (wer hat die Sperre). Wenn Sie andererseits über andere herkömmliche Push-Benachrichtigungskanäle wie E-Mail kommunizieren müssen, an wen senden Sie die Benachrichtigung? Sie wissen nicht im Voraus, wer die Datei möglicherweise bearbeiten möchte, insbesondere bei Open Source-Projekten, es sei denn, Sie haben eine vollständige Liste Ihres gesamten Entwicklungsteams. Diese traditionellen Kommunikationsmethoden sind also bei weitem nicht so effektiv.

Ein zentraler Sperrserver verstößt zwar gegen die Prinzipien von DVCS, ist jedoch die einzig mögliche Methode für nicht zusammenführbare Dateien. Solange DVCS keine Zentralverriegelungsfunktion hat, wird das Unternehmen, für das ich arbeite, Subversion behalten.

Die bessere Lösung wäre, ein Zusammenführungstool für alle Ihre binären Dateiformate zu erstellen. Dies ist jedoch ein längerfristiges und kontinuierliches Ziel, das niemals "abgeschlossen" werden kann.

Hier ist eine interessante Lektüre zum Thema.

Ich bin damit einverstanden, dass das Sperren von Binärdateien für einige Umgebungen eine notwendige Funktion ist. Ich habe mir gerade überlegt, wie ich das umsetzen soll:

• Sie können eine Datei als "Needs-Lock" markieren (wie die Eigenschaft "svn: Need-Lock").
• Beim Auschecken würde git eine solche Datei als schreibgeschützt markieren.
• Ein neuer Befehl git-lock würde einen zentralen Sperrserver kontaktieren, der irgendwo ausgeführt wird, um die Erlaubnis zum Sperren zu erhalten.
• Wenn der Sperrserver die Berechtigung erteilt, markieren Sie die Datei Lese- / Schreibzugriff.
• git-add würde den Sperrserver über den Inhalts-Hash der gesperrten Datei informieren.
• Der Sperrserver würde darauf achten, dass dieser Inhalts-Hash in einem Commit im Master-Repository angezeigt wird.
• Wenn der Hash angezeigt wird, lassen Sie die Sperre los.

Dies ist eine halbherzige Idee und es gibt überall potenzielle Löcher. Es widerspricht auch dem Geist von Git, kann aber in einigen Zusammenhängen durchaus nützlich sein.

Innerhalb einer bestimmten Organisation könnte diese Art von Dingen möglicherweise mit einer geeigneten Kombination aus Skript-Wrappern und Commit-Hooks erstellt werden.

Als Reaktion auf Marios zusätzliche Besorgnis über Änderungen, die an mehreren Stellen in den Binärdateien vorgenommen wurden. Das Szenario ist also, dass Alice und Bob beide gleichzeitig Änderungen an derselben binären Ressource vornehmen. Sie haben jeweils ein eigenes lokales Repo, das von einer zentralen Fernbedienung geklont wurde.

Dies ist in der Tat ein potenzielles Problem. Also beendet Alice zuerst und schiebt sich zum zentralen alice/updateZweig. Normalerweise würde Alice in diesem Fall eine Ankündigung machen, dass dies überprüft werden sollte. Bob sieht das und überprüft es. Er kann entweder (1) diese Änderungen selbst in seine Version aufnehmen (verzweigen alice/updateund Änderungen daran vornehmen) oder (2) seine eigenen Änderungen an veröffentlichenbob/update . Wieder macht er eine Ankündigung.

Wenn Alice masterstattdessen drängt, hat Bob ein Dilemma, wenn er ziehtmaster und versucht, sich in seine lokale Niederlassung zu integrieren. Seine Konflikte mit Alice. Aber auch hier kann das gleiche Verfahren angewendet werden, nur für verschiedene Zweige. Und selbst wenn Bob alle Warnungen ignoriert und sich zu Alice verpflichtet, ist es immer möglich, Alice zu verpflichten, Dinge zu reparieren. Dies wird einfach zu einem Kommunikationsproblem.

Da (AFAIK) die Subversion-Sperren nur als Hinweis dienen, kann eine E-Mail oder Sofortnachricht denselben Zweck erfüllen. Aber selbst wenn Sie das nicht tun, können Sie es mit Git beheben.

Nein, es gibt keinen Verriegelungsmechanismus an sich. Ein Verriegelungsmechanismus ist jedoch in der Regel nur ein Ersatz für eine gute Kommunikation. Ich glaube, deshalb haben die Git-Entwickler keinen Sperrmechanismus hinzugefügt.

Wir haben erst kürzlich angefangen, Git zu verwenden (zuvor verwendete Subversion), und ich habe eine Änderung am Workflow gefunden, die bei Ihrem Problem helfen kann, ohne dass Sperren erforderlich sind. Es nutzt den Vorteil, wie Git gestaltet ist und wie einfach Zweige sind.

Im Grunde läuft es darauf hinaus, zu einem Nicht-Master-Zweig zu wechseln, diesen Zweig zu überprüfen und dann in den Hauptzweig (oder den jeweiligen Zweig) zu verschmelzen.

So wie git "verwendet" werden soll, veröffentlicht jeder Entwickler sein eigenes öffentliches Repository, aus dem andere aufgefordert werden, es abzurufen. Ich habe festgestellt, dass Subversion-Benutzer Probleme damit haben. Stattdessen werden Zweigbäume im zentralen Repository verzweigt, wobei jeder Benutzer seinen eigenen Zweigbaum hat. Zum Beispiel könnte eine Hierarchie wie diese funktionieren:

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

Fühlen Sie sich frei, Ihre eigene Struktur zu verwenden. Hinweis: Ich zeige auch Themenzweige, eine andere gängige Git-Sprache.

Dann in einem lokalen Repo für Benutzer a:

feature1
feature2

Und um es zum zentralen Server (Ursprung) zu bringen:

git push origin feature1:users/a/feature1

(Dies kann wahrscheinlich durch Konfigurationsänderungen vereinfacht werden.)

Sobald Feature1 überprüft wurde, führt derjenige, der dafür verantwortlich ist (in unserem Fall ist es der Entwickler des Features, Sie könnten einen einzelnen Benutzer haben, der für das Zusammenführen von Zusammenführungen verantwortlich ist) Folgendes aus:

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

Der Pull führt einen Abruf durch (Ziehen aller neuen Master-Änderungen und des Feature-Zweigs) und der Update-Master auf das, was das zentrale Repository hat. Wenn Benutzer a seine Arbeit erledigt und den Master ordnungsgemäß verfolgt hat, sollte es keine Probleme mit der Zusammenführung geben.

All dies bedeutet, dass selbst wenn ein Benutzer oder ein Remote-Team eine Änderung an einer binären Ressource vornimmt, diese überprüft wird, bevor sie in den Hauptzweig aufgenommen wird. Und es gibt eine klare Abgrenzung (basierend auf dem Prozess), wann etwas in den Hauptzweig geht.

Sie können Aspekte davon auch programmgesteuert mithilfe von Git-Hooks durchsetzen, aber ich habe noch nicht mit diesen gearbeitet, kann also nicht darüber sprechen.

Es lohnt sich, Ihren aktuellen Workflow zu überprüfen, um festzustellen, ob das Sperren von Bildern wirklich erforderlich ist. Es ist relativ ungewöhnlich, dass zwei Personen ein Bild unabhängig voneinander bearbeiten, und ein bisschen Kommunikation kann viel bewirken.

Ich habe dieses Problem in Git-Diskussionsgruppen diskutiert und bin zu dem Schluss gekommen, dass es derzeit keine vereinbarte Methode zum zentralen Sperren von Dateien für Git gibt.

Als ich Subversion verwendete, habe ich die svn:needs-lockEigenschaft religiös für alle binären und sogar schwer zu bearbeitenden Textdateien festgelegt. Ich nie Konflikte erlebt.

In Git mache ich mir keine Sorgen um solche Dinge. Denken Sie daran: Sperren in Subversion sind eigentlich keine obligatorischen Sperren, sondern lediglich Kommunikationsmittel. Und raten Sie mal: Ich brauche keine Subversion, um zu kommunizieren. Ich kann gut mit E-Mail, Telefon und Sofortnachrichten umgehen.

Eine andere Sache, die ich getan habe, ist, viele Binärformate durch Nur-Text-Formate zu ersetzen. Ich verwende reStructuredText oder LaΤ _Ε Χ anstelle von Word, CSV anstelle von Excel, ASCII-Art anstelle von Visio, YAML anstelle von Datenbanken, SVG anstelle von OO Draw, abc anstelle von MIDI und so weiter.

Dies ist keine Lösung, sondern ein Kommentar dazu, warum Verriegelungsmechanismen benötigt werden. In einigen Bereichen werden einige Tools verwendet, die nur Binärformate verwenden, die absolut geschäftskritisch sind, und die Option "Bessere / andere Tools verwenden" ist einfach keine Option. Es gibt keine brauchbaren alternativen Werkzeuge. Diejenigen, mit denen ich vertraut bin, wären wirklich keine Kandidaten für das Zusammenführen, selbst wenn Sie dieselben Informationen in einem ASCII-Format gespeichert hätten. Ein Einwand, den ich gehört habe, ist, dass Sie offline arbeiten möchten. Das spezielle Tool, an das ich denke, funktioniert sowieso nicht offline, da Lizenzen gezogen werden müssen. Wenn ich also Daten auf einem Laptop habe, kann ich das Tool sowieso nicht ausführen, während ich in einem Zug bin. Das heißt, was git bietet, wenn ich eine langsame Verbindung habe, Ich kann Lizenzen erhalten und auch Änderungen abrufen, habe aber die schnelle lokale Kopie, um verschiedene Versionen anzusehen. Das ist eine schöne Sache, die Ihnen das DVCS auch in diesem Fall bietet.

Ein Gesichtspunkt ist, dass Git einfach nicht das zu verwendende Tool ist, aber es ist gut für alle Textdateien, die auch damit verwaltet werden, und es ist ärgerlich, verschiedene Tools zur Versionskontrolle für verschiedene Dateien zu benötigen.

Die Art der Empfehlung, per E-Mail zu sperren, stinkt wirklich. Ich habe das gesehen und war müde von einem endlosen Strom von E-Mails mit dem Titel "Ich bearbeite es", "Ich bin mit der Bearbeitung fertig" und habe gesehen, dass Änderungen dadurch verloren gegangen sind. Der besondere Fall, an den ich denke, war einer, bei dem eine Sammlung kleinerer ASCII-Dateien viel schöner gewesen wäre, aber das ist eine Seite.

Ich würde nicht erwarten, dass das Sperren von Dateien jemals zu einer Funktion in Git wird. Für welche Art von Binärdateien interessieren Sie sich hauptsächlich? Sind Sie tatsächlich daran interessiert, die Dateien zu sperren oder Konflikte zu verhindern, die dadurch verursacht werden, dass sie nicht zusammengeführt werden können?

Ich erinnere mich an jemanden, der über die Unterstützung für das Zusammenführen von OpenOffice-Dokumenten in Git spricht (oder diese sogar implementiert).

Was ist mit CAD-Dateien? Wenn die Dateien nicht gesperrt sind, um auch schreibgeschützt zu bleiben, öffnen die meisten CAD-Programme sie nur, um beliebige Bits zu ändern, die von jedem VC als neue Datei angesehen werden. Meiner Ansicht nach ist das Sperren ein ideales Mittel, um Ihre Absicht zu kommunizieren, eine bestimmte Datei zu ändern. Außerdem wird verhindert, dass Software überhaupt Schreibzugriff erhält. Dies ermöglicht Aktualisierungen der lokalen Dateien, ohne dass die Software oder zumindest alle Dateien vollständig geschlossen werden müssen.

TortoiseGit unterstützt den vollständigen Git-Workflow für Office-Dokumente, die Diff an Office selbst delegieren. Es funktioniert auch beim Delegieren an OpenOffice für OpenDocument-Formate.

Ich schlage nicht vor, Git in meiner Firma für das gleiche Problem zu verwenden. Wir verwenden EA für alle unsere Designs und Microsoft Word für die Dokumentation. Wir wissen nicht im Voraus, wer eine bestimmte Datei bearbeiten darf, daher ist exklusives Sperren unsere einzige Option.

git funktioniert sehr gut in einer Umgebung ohne Team, in der jeder Entwickler allein für einen Code oder eine Datei verantwortlich ist, da in diesem Fall keine Kommunikation über Sperren erforderlich ist.

Wenn Ihre Organisation eine Teamumgebung benötigt (normalerweise, um Entwicklern die Arbeitsplatzsicherheit zu entziehen), verwenden Sie svn, git ist nichts für Sie. Svn bietet sowohl Quellcodeverwaltung als auch Kommunikation zwischen Entwicklern über Sperren.

Fügen Sie einfach eine Textdatei mit der Datei, die Sie sperren möchten, in cc ein und lassen Sie sie vom Update-Hook ablehnen.

Es mag sein, dass die Reorganisation eines Projekts dazu beitragen kann, Sperren zu vermeiden, aber:

• Die Teams sind auch nach anderen Prioritäten organisiert (Standort, Kunden, ...).
• Die Tools werden auch von anderen Zielen ausgewählt (Kompatibilität, Preis, Benutzerfreundlichkeit für die meisten Mitarbeiter).
• Einige Tools (und daher auch Binärdateien) können nicht vermieden werden, da es einfach keinen Ersatz gibt, der den gleichen Job erledigen kann und der für den gleichen Preis den Anforderungen des Unternehmens entspricht.

Es klingt ziemlich ineffizient, zu verlangen, dass ein ganzes Unternehmen seinen Workflow neu organisiert und alle Tools ersetzt, die Binärdateien erzeugen, nur um mit Git arbeiten zu können, da keine Sperren vorhanden sind.

Sperren passen nicht in die Git-Philosophie (die nie für Binärdateien entwickelt wurde), aber es gibt nicht zu vernachlässigende Situationen, in denen Sperren der effizienteste Weg sind, ein solches Problem zu lösen.

Git stellt keinen Befehl zum Sperren von Dateien bereit, aber ich habe einen Weg finanziert, um diese Funktion mithilfe von Git-Hooks zu erreichen. Zum Speichern der Sperrinformationen wird ein Hilfsserver benötigt. Wir können einen Pre-Commit-Hook verwenden, um zu überprüfen, ob eine der festgeschriebenen Dateien gesperrt ist. Und wenn jemand eine Datei sperrt, sollte ein Programm dem Hilfsserver die Informationen des Schließfachs und der gesperrten Datei mitteilen.