Ich habe eine Datei, die in Git eingecheckt ist. Die Datei muss einen API-Schlüssel enthalten, aber ich möchte den API-Schlüssel aus Sicherheitsgründen nicht an Git übergeben. Anstelle eines API-Schlüssels habe ich erläutert, wie ein API-Schlüssel für jeden Entwickler generiert wird.
Ich möchte nicht, dass ein Entwickler versehentlich seinen API-Schlüssel festschreibt und die Basisdatei überschreibt.
Ich habe:
.gitignore -Datei hinzugefügt, aber da sie bereits festgeschrieben wurde, macht dies nichts. git update-index --assume-unchanged myFile.js
Ich bin jedoch gerade auf meinen Laptop gegangen, habe vergessen, den Befehl auszuführen, und versehentlich einen Schlüssel für den Repo festgelegt. Ich suche nach einer ausfallsichereren Methode. Im Wesentlichen möchte ich eine erste Version der Datei an GitHub übergeben und dann Modifikationen dieser Datei verbieten.
Ist das möglich?
Als Referenz sieht die Datei etwa so aus:
%Vor% Ein möglicher Ansatz wäre die Installation einiger serverseitig hook (zB update ), das wäre
Natürlich würde ein solcher serverseitiger Hook die Mitwirkenden nicht davon abhalten, Commits zu erstellen (lokal auf ihren Rechnern), die eine andere Version der Datei enthalten. Nachdem sie jedoch einige ihrer Stöße zurückgewiesen gesehen hatten, würden sie sicherlich die Lektion lernen. :p
Die Antwort auf die implizierte Betreffzeile ("Kann ich git eine bestimmte Datei als schreibgeschützt auschecken") ist "Nein, zumindest nicht direkt", da git nur ein einziges Berechtigungsbit pro Datei speichert: executable oder nicht ausführbar. Alle anderen Bits sind für jede Datei gleich eingestellt.
Allerdings gibt es ein paar Tricks mit Haken. Wie einige Kommentatoren vorgeschlagen haben, können Sie etwas in einem serverseitigen Hook testen, um Push-Angriffe zu vermeiden. Sie können Wisch- und Reinigungsfilter verwenden. Sie können einen post-checkout Hook setzen, der die Datei schreibgeschützt setzt.
Der Nachteil aller Hooks ist, dass sie für jedes Repository eingerichtet werden müssen und Benutzer sie außer Kraft setzen können (mit Ausnahme eines serverseitigen Hooks, vorausgesetzt, der Benutzer hat keinen direkten Zugriff auf den Server). 1 Dies ist auch der Vorteil eines Hooks, obwohl es für naive Benutzer eher ein Nachteil als ein Vorteil ist, da Git selbst die Hooks nicht automatisch einrichten wird.
Der post-checkout Hook ist wahrscheinlich der offensichtlichste Ort, um Dateiberechtigungen festzulegen, da die Dokumentation von git dieses Bit enthält:
Dieser Hook kann verwendet werden, um ... die Eigenschaften von Arbeitsverzeichnissen festzulegen.
Praktischerweise wird der Hook immer im Verzeichnis der obersten Ebene ausgeführt, unabhängig davon, wo sich der Benutzer befindet, solange sich der Benutzer tatsächlich in der git work tree befindet. 2 Das ist also sehr einfach hook reicht aus, um eine Datei in schreibgeschützt zu ändern:
%Vor% (auf jedem System mit chmod auf jeden Fall, und denken Sie daran, den Anschluss als ausführbare Datei einzurichten).
Der Benutzer muss diesen Hook in sein Repository einfügen, in .git/hooks/post-checkout (obwohl Sie die Datei selbst in das Repository übertragen können, und dann den Benutzer kopieren oder verknüpfen, vielleicht durch ein zusätzliches Setup-Skript) .
1 Daher ist ein serverseitiger Hook der richtige Ort, wenn Sie eine Richtlinie strikt durchsetzen wollen (dies gilt im Allgemeinen).
2 Das heißt, das Folgende besiegt den Haken:
%Vor% Hier ist das aktuelle Arbeitsverzeichnis nur /tmp , und es gibt keine Möglichkeit für den Hook herauszufinden, was es sein soll (Sie können $GIT_DIR lesen, aber das ist nicht unbedingt hilfreich, da das Verzeichnis .git benötigt wird nicht direkt mit dem Arbeitsbaum verbunden sein, und dafür ist die Einstellung GIT_DIR überhaupt gedacht.
Beachten Sie, dass nicht den Hook besiegt, wenn er in der Arbeitsstruktur in einem Unterverzeichnis ist; das ist, was ich meine "scheint immer im obersten Verzeichnis ausgeführt zu werden".
Wenn Sie nicht möchten, dass Entwickler bestimmte Änderungen in das Repository einfügen, ist es eine gute Lösung, das Repository zu sperren und stattdessen ein Review-System wie Gerrit zu verwenden. Einzelne Änderungen werden stattdessen in Gerrit geschoben und müssen Peer Review bestehen.
Jedes Commit, das eine Datei hinzufügt, die lokal sein soll, wie eine API-Schlüsseldatei oder eine kompilierte Objektdatei, kann zurückgewiesen werden.
Der Entwickler kann dann das Commit überarbeiten, indem er es neu einfügt, um die anstößige Datei nicht einzuschließen, und erneut zur Überprüfung einreichen. Wenn die Überprüfung bestanden wird, wird sie in den entsprechenden Zielzweig übernommen.
Eine andere Lösung ist:
myFile_template.js zu kopieren und die Details zu bearbeiten myFile.js zu myFile.js hinzu
Immer noch keine sehr robuste Lösung, da die Entwickler immer noch die Informationen festschreiben können, die Sie verstecken wollen, aber die Datei wird zumindest nicht in der Statusliste angezeigt.
Tags und Links git