it-swarm.com.de

Sperren von Binärdateien mit dem Versionskontrollsystem von git

Seit anderthalb Jahren habe ich mein Augenmerk auf die Git-Community gerichtet, 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 letzten Jahres habe ich noch keine Entwicklungen in dieser Frage gesehen. Ich verstehe, dass das Sperren von Dateien gegen die grundlegenden Prinzipien der verteilten Quellcodeverwaltung verstößt. Ich sehe jedoch nicht, wie ein Webentwicklungsunternehmen git dazu nutzen kann, Änderungen von Quellcode und Bilddateien zu verfolgen, wenn Konflikte mit binären Dateien auftreten können.

Um die Auswirkungen des Sperrens zu erreichen, muss ein "zentrales" Repository identifiziert werden. Unabhängig vom verteilten Charakter von git verfügen die meisten Unternehmen über ein "zentrales" Repository für ein Softwareprojekt. Wir sollten in der Lage sein, eine Datei als unter dem angegebenen git-Repository an einer angegebenen Adresse zu sperren. Vielleicht wird das schwierig, weil git Dateiinhalt nicht Dateien verfolgt?

Haben einige von Ihnen Erfahrung im Umgang mit Git und Binärdateien, die vor der Änderung gesperrt werden sollten?

ANMERKUNG: Offenbar hat das neue verteilte Versionskontrollprojekt von Source Gear, Veracity, das Sperren als eines seiner Ziele.

72
Mario

Git LFS 2.0 hat das Sperren von Dateien hinzugefügt.

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

Dadurch werden Zusammenführungskonflikte sowie verlorene Arbeit an nicht zusammenlegbaren Dateien auf Dateisystemebene verhindert. Auch wenn dies scheinbar der verteilten und parallelen Natur von Git widerspricht, ist das Sperren von Dateien ein wichtiger Bestandteil vieler Software-Entwicklungsworkflows - insbesondere für größere Teams, die mit binären Assets arbeiten.

6
osowskit

Subversion hat Sperren und sie sind nicht nur beratend. Sie können mit dem svn:needs-lock-Attribut erzwungen werden (können aber bei Bedarf auch bewusst gebrochen werden). Dies ist die richtige Lösung für die Verwaltung nicht zusammenlegbarer Dateien. Die Firma, für die ich arbeite, speichert fast alles in Subversion und verwendet svn:needs-lock für alle nicht zusammenlegbaren Dateien.

Ich stimme nicht zu "Sperren sind nur eine Kommunikationsmethode". Sie sind eine wesentlich effektivere Methode als Push-Benachrichtigungen wie Telefon oder E-Mail. Subversion-Sperren sind selbstdokumentierend (wer hat die Sperre). Wenn Sie jedoch ü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 bearbeiten möchte, insbesondere bei Open-Source-Projekten, es sei denn, Sie haben eine vollständige Liste Ihres gesamten Entwicklungsteams. Daher sind diese traditionellen Kommunikationsmethoden bei weitem nicht so effektiv.

Ein zentraler Sperrserver ist zwar gegen die Prinzipien von DVCS, aber die einzig mögliche Methode für nicht zusammenlegbare Dateien. Solange DVCS nicht über eine zentrale Sperrfunktion verfügt, wird das Unternehmen, an dem ich arbeite, für Subversion arbeiten.

Die bessere Lösung wäre, ein Zusammenführungswerkzeug für alle Ihre Binärdateiformate zu erstellen. Dies ist jedoch ein längerfristiges und fortlaufendes Ziel, das niemals "abgeschlossen" wird.

Hier ist eine interessante Lektüre zum Thema.

74
Craig McQueen

Ich stimme zu, dass das Sperren von Binärdateien für einige Umgebungen eine notwendige Funktion ist. Ich hatte nur einen Gedanken darüber, wie ich das umsetzen sollte:

  • Sie haben die Möglichkeit, eine Datei als "needs-lock" zu markieren (wie die Eigenschaft "svn: needs-lock").
  • Beim Auschecken markiert git eine solche Datei als schreibgeschützt.
  • Ein neuer Befehl git-lock würde einen zentralen Sperrserver anrufen, der irgendwo ausgeführt wird, um die Berechtigung zum Sperren anzufordern.
  • Wenn der Sperrserver die Berechtigung erteilt, markieren Sie die Datei als Lese- und Schreibzugriff.
  • git-add würde den Sperrserver über den Inhaltshash der gesperrten Datei informieren.
  • Der Sperrserver würde darauf achten, dass der Inhalts-Hash in einem Commit im Master-Repository angezeigt wird.
  • Wenn der Hash angezeigt wird, geben Sie die Sperre frei.

Dies ist eine sehr halbe Sache und es gibt potentielle Löcher überall. Es widerspricht auch dem Geist des Idioten, kann aber in manchen Zusammenhängen durchaus nützlich sein.

In einer bestimmten Organisation könnten diese Dinge möglicherweise mithilfe einer geeigneten Kombination aus Skript-Wrappern und Commit-Hooks erstellt werden.

10
Greg Hewgill

Als Reaktion auf Marios zusätzliche Besorgnis über Änderungen an mehreren Stellen der Binärdateien. Das Szenario ist also, dass Alice und Bob gleichzeitig Änderungen an derselben binären Ressource vornehmen. Sie verfügen jeweils über ein eigenes lokales Repo, das von einer zentralen Fernbedienung aus geklont wird.

Dies ist in der Tat ein potenzielles Problem. Alice beendet also zuerst und drückt zum zentralen alice/update-Zweig. Normalerweise gibt Alice in diesem Fall eine Ankündigung aus, dass sie überprüft werden sollte. Bob sieht das und prüft es. Er kann diese Änderungen entweder selbst (1) in seine Version einbauen (von alice/update abzweigen und Änderungen daran vornehmen) oder (2) seine eigenen Änderungen an bob/update veröffentlichen. Wieder macht er eine Ankündigung.

Wenn nun Alice stattdessen auf master drückt, hat Bob ein Dilemma, wenn er master zieht und versucht, sich in seinen lokalen Zweig zu mischen. Seine Konflikte mit Alice. Das gleiche Verfahren kann jedoch auch auf verschiedene Branchen angewendet werden. Und selbst wenn Bob alle Warnungen ignoriert und sich bei Alice einsetzt, ist es immer möglich, Alices Verpflichtung zur Behebung von Problemen herauszuziehen. Dies wird einfach zu einem Kommunikationsproblem.

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

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

10
Michael Johnson

Wir haben kürzlich mit Git (früher Subversion verwendet) begonnen, und ich habe eine Änderung des Arbeitsflusses gefunden, die bei Ihrem Problem hilfreich sein könnte, ohne dass Sperren erforderlich sind. Es nutzt das Design von git und die einfachen Zweige.

Im Grunde läuft es darauf hinaus, zu einem Nicht-Master-Zweig zu wechseln, diesen Zweig zu überprüfen und dann mit dem Master-Zweig (oder was auch immer der Ziel-Zweig ist) zusammenzuführen.

Die Art und Weise, wie "git" verwendet werden soll, veröffentlicht jeder Entwickler sein eigenes öffentliches Repository, von dem er andere anfordert. Ich habe festgestellt, dass Subversion-Benutzer Probleme damit haben. Stattdessen verzweigen wir zu Verzweigungsbäumen im zentralen Repository, wobei jeder Benutzer über eine eigene Zweigstruktur verfügt. Zum Beispiel könnte eine solche Hierarchie 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 Idiomart.

Dann in einem lokalen Repo für Benutzer a:

feature1
feature2

Und um es auf den zentralen Server (Origin) zu bringen:

git Push Origin feature1:users/a/feature1

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

Nach der Überprüfung von feature1, wer auch immer dafür verantwortlich ist (in unserem Fall ist es der Entwickler der Funktion, könnten Sie einen einzelnen Benutzer für die Zusammenführung mit dem Master verantwortlich machen):

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

Der Pull-Vorgang führt einen Abruf (durch Ziehen aller neuen Master-Änderungen und des Feature-Zweigs) und des Update-Masters auf das, was das zentrale Repository hat. Wenn ein Benutzer seinen Job ordnungsgemäß ausgeführt und den Master ordnungsgemäß verfolgt hat, sollten beim Zusammenführen keine Probleme auftreten.

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 Master-Zweig integriert wird. Und es gibt eine klare Abgrenzung (prozessabhängig), wann etwas in den Master-Zweig geht.

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

8
Michael Johnson

Bei der Verwendung von Subversion habe ich die Eigenschaft svn:needs-lock für alle Binärdateien und sogar für die schwer zu bearbeitenden Textdateien religiös festgelegt. Ich nie habe tatsächlich Konflikte erlebt.

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

Eine andere Sache, die ich getan habe, ist, viele Binärformate durch Nur-Text-Formate zu ersetzen. Ich benutze 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.

6
Jörg W Mittag

Es lohnt sich, Ihren aktuellen Workflow zu untersuchen, um zu sehen, ob das Sperren von Bildern wirklich notwendig ist. Es ist relativ ungewöhnlich, dass zwei Personen ein Bild unabhängig voneinander bearbeiten, und ein bisschen Kommunikation kann einen langen Weg gehen.

5
Khoth

Ich habe dieses Thema in Git-Diskussionsgruppen erörtert und bin zu dem Schluss gekommen, dass es derzeit keine keine Methode für die zentrale Dateisperre für Git gibt.

3
Mario

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

2

Was ist mit CAD-Dateien? Wenn die Dateien nicht gesperrt sind, um auch schreibgeschützt zu bleiben, öffnen die meisten CAD-Programme sie, um beliebige Bits zu ändern, die von allen vcs als neue Datei angesehen werden. Aus meiner Sicht ist das Sperren ein ideales Mittel, um zu kommunizieren, ob Sie beabsichtigen, eine Teiledatei zu ändern. Außerdem wird verhindert, dass einige Software überhaupt Schreibzugriff erhält. Dies ermöglicht Updates der lokalen Dateien, ohne dass die Software oder zumindest alle Dateien vollständig geschlossen werden müssen.

1
aproposd

Fügen Sie einfach eine Textdatei in cc mit der Datei ein, die Sie sperren möchten, und lassen Sie sie dann vom Aktualisierungshaken abweisen.

1
Remote Shell

Es mag richtig sein, dass das Umorganisieren eines Projekts dazu beitragen kann, Sperren zu vermeiden, aber:

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

Die Forderung, dass ein ganzes Unternehmen seinen Workflow umstrukturiert und alle Werkzeuge, die Binaries erzeugen, ersetzt, nur um mit Git arbeiten zu können, weil es an Sperren mangelt, klingt das ziemlich ineffizient.

Sperren passen nicht in die git-Philosophie (die für Binärdateien nie gemacht wurde), aber es gibt nicht vernachlässigbare Situationen, in denen Sperren die effizienteste Lösung für ein solches Problem sind.

1
Stefan

Ich würde nicht erwarten, dass Dateisperren es jemals zu einem Feature in git machen. Für welche Art von Binärdateien interessieren Sie sich in erster Linie? Sind Sie tatsächlich daran interessiert, die Dateien zu sperren oder Konflikte zu verhindern, die durch das Zusammenführen der Dateien verursacht werden können?.

Ich erinnere mich an jemanden, der Unterstützung für das Zusammenführen von OpenOffice-Dokumenten in git gesprochen (oder sogar implementiert) hat.

1
JesperE

Dies ist keine Lösung, sondern ein Kommentar, warum Schließmechanismen benötigt werden. In einigen Bereichen werden einige Tools verwendet, bei denen nur binäre Formate verwendet werden, die für den Einsatz in Unternehmen äußerst wichtig sind. Das "bessere/andere Tools verwenden" ist einfach keine Option. Es gibt keine realisierbaren alternativen Werkzeuge. Diejenigen, die mir bekannt sind, wären wirklich keine Kandidaten für das Zusammenführen, selbst wenn Sie dieselben Informationen in einem ASCII-Format gespeichert haben. Ein Einwand, den ich gehört habe, ist, dass Sie offline arbeiten möchten. Das spezielle Tool, an das ich gerade denke, funktioniert sowieso nicht offline, weil ich Lizenzen ziehen muss. Wenn ich also Daten auf einem Laptop habe, kann ich das Tool sowieso nicht laufen lassen, während es sich in einem Zug befindet. Das heißt, was git bietet, wenn ich eine langsame Verbindung habe, kann ich Lizenzen bekommen und auch Änderungen runterziehen, habe aber die schnelle lokale Kopie, um verschiedene Versionen zu betrachten. Das ist eine schöne Sache, die das DVCS Ihnen auch in diesem Fall gibt.

Ein Gesichtspunkt ist, dass git einfach nicht das zu verwendende Werkzeug ist, aber es ist nett für alle Textdateien, die auch damit verwaltet werden, und es ist ärgerlich, verschiedene Versionskontrollwerkzeuge für verschiedene Dateien zu benötigen. 

Die Art von Advisory-Locking-via-Mail-Ansatz stinkt wirklich. Ich habe das gesehen und war müde von einem endlosen Strom von E-Mails von "Ich bearbeite es" "Ich bin fertig mit der Bearbeitung" und habe dabei Änderungen gesehen. Der besondere Fall, an den ich denke, war einer, in dem eine Sammlung kleinerer ASCII-Dateien viel schöner gewesen wäre, aber das ist ein Nebeneffekt.

1
Dan

Ich schlage nicht vor, git in meinem Unternehmen für dasselbe Problem einzusetzen. Wir verwenden EA für alle unsere Designs und Microsoft Word für die Dokumentation. Wir wissen nicht, wer eine bestimmte Datei bearbeiten darf. Ausschließliches Sperren ist daher unsere einzige Option.

0
Hernan Rajchert

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

Wenn Ihre Organisation eine Teamumgebung erfordert (normalerweise, um Entwickler von der Jobsicherheit zu befreien), verwenden Sie svn. Git ist nicht für Sie. Svn bietet sowohl die Quellcodeverwaltung als auch die Kommunikation zwischen Entwicklern über Sperren.

0
alpav

Git bietet keinen Befehl zum Sperren von Dateien, aber ich habe einen Weg gefunden, um diese Funktion mithilfe von Git Hooks zu erreichen .. Ein Hilfsserver ist zum Speichern der Sperrinformationen erforderlich. Wir können einen Pre-Commit-Hook verwenden, um zu prüfen, ob eine der festgeschriebenen Dateien gesperrt ist. Wenn jemand eine Datei sperrt, sollte ein Programm dem Hilfsserver die Informationen über das Schließfach und die gesperrte Datei mitteilen.

0
Cherler Ton