Hatte heute den Code (die gesamte Projekthistorie) in einen anderen Dev-Shop zu transferieren und fragte mich, ob es eine gute Idee ist, das bloße Git-Repository, das unser Team zur Zusammenarbeit verwendet, zu verschicken und einfach wörtlich zu senden?
Ist das als solches sicher?
Sind vertrauliche Daten in einem .git-Ordner gespeichert?
Wenn Sie dies tun, anstatt clone oder bundle zu verwenden, geben Sie auch Ihr .git/hooks -Verzeichnis, .git/config -Datei und ein paar andere anpassbare Dateien an. Es ist nicht üblich, dass diese Dateien sensible Daten enthalten (Sie würden es wissen, weil Sie sie manuell dort abgelegt hätten), aber sie können personalisierte Einstellungen enthalten. Beispielsweise haben Sie möglicherweise die Einstellungen user.name und user.email config in .git/config festgelegt. Es ist möglich, dass Sie möglicherweise ein Hook-Skript (in .git/hooks/* ) geschrieben haben, das Passwörter enthalten könnte - aber, wie ich bereits sagte, würden Sie wahrscheinlich schon davon wissen.
Aber, git speichert keines Ihrer Passwörter oder andere geheime / sensible Daten.
Schauen Sie in Ihr .git -Verzeichnis. Es kann viele Dateien geben, aber sie fallen in eine relativ kleine Anzahl von regulären Gruppen (Objektspeicherdaten, Refs, Reflogs usw.). Sie können die Inhalte in zwei Hauptkategorien unterteilen: Daten, die Git normalerweise in andere Repositorys transportieren kann, und Daten, die Git normalerweise nicht in andere Repositories transportieren würde.
Normalerweise nicht transportiert:
HEAD , FETCH_HEAD , ORIG_HEAD , MERGE_HEAD
config description hooks/ index info/ - Verschiedenes logs/ - reflogs Normalerweise transportiert (z. B. über Klone, Fetches, Pushs und Bundles):
objects/ packed-refs refs/ Diese letzte Gruppe bildet den Objektspeicher und seine veröffentlichten Einstiegspunkte. Sie müssen natürlich den versionierten Inhalt selbst überprüfen, um festzustellen, ob es etwas Feines darin gibt.
Die HEADs, das index (nicht in einem leeren Repository vorhanden) und die Reflogs ( logs/ ) sind alle zusätzliche Einstiegspunkte in den Objektspeicher. Wenn Sie ein History-Rewriting durchgeführt haben (z. B. haben Sie kürzlich eine sensible Konfigurationsdatei aus dem aufgezeichneten Verlauf gelöscht), sollten Sie besonders auf die Reflogs achten (wahrscheinlich in den meisten blanken Repositories nicht aktiviert) und auf die Refs / Original / Teil der Refs Namensraum.
FETCH_HEAD und config können die Adressen verwandter Git-Repositories enthalten.
config könnte andere vertrauliche Informationen enthalten.
info/ hat verschiedene Informationen; einige davon könnten empfindlich sein (Info / Alternativen); manche sind weniger sensibel (vorausgesetzt, der Inhalt selbst ist "sauber" -info / refs, info / packs); einige könnten für den Betrieb des Endlagers wichtig sein (Info / Grafts). Alle Add-On-Tools, die Sie verwenden (Hook-Skripte, Web-Schnittstellen usw.), können Daten hier speichern. einige davon können empfindlich sein (Zugriffskontrolllisten usw.).
Wenn in hooks/ etwas aktiv ist, sollten Sie prüfen, ob es mit der Kopie des Repositorys versehen werden soll (prüfen Sie auch, ob zusätzliche Daten irgendwo im Repository gespeichert werden).
Die description -Datei ist wahrscheinlich unschädlich, aber Sie können es genauso gut überprüfen.
Wenn Sie den Inhalt nur übergeben, sollten Sie wahrscheinlich einfach in ein neues blasses Repository klonen oder ein Paket verwenden (git bundle als VonC beschreibt ).
Wenn Sie für die Übergabe des Inhalts verantwortlich sind, sowie für den Prozess, mit dem Sie ihn verwalten, müssen Sie jedes Bit des Repositorys einzeln untersuchen.
Im Allgemeinen (oder auf eine eher "paranoide" Art) gibt es viele Stellen in der Hierarchie eines Git-Repositories, in denen jemand eine zufällige Datei speichern könnte. Wenn Sie sichergehen möchten, dass Sie nur Daten weitergeben, die Git benötigt, sollten Sie einen Klon oder ein Bündel verwenden. Wenn Sie einige Ihrer "pro-Repository" -Daten liefern müssen (z. B. ein Hook, der das Repository verwaltet), sollten Sie in ein neues leeres Repository klonen (verwenden Sie eine file: URL, um das Kopieren und Fixieren existierender Objektspeicherdateien zu vermeiden) und installieren Sie nur die Hooks / Daten neu, die benötigt werden, um Ihre Verpflichtungen zu erfüllen.
Eine ähnliche Lösung wäre eine git bundle .
Siehe Sicherung von github repo oder Backup eines lokalen Git-Repository für mehr.
Das .git (entweder gebündelt oder komprimiert ) enthält keine sensiblen Daten außer dem gesamten Verlauf und den Dateien, die Sie darin abgelegt haben.
Siehe git - Datei aus dem Repository entfernen , um sie beispielsweise zu entfernen sensible Daten.
Wie Pat Notz in seine Antwort , eine komprimierte .git enthält deine .git/config .
Mir ist klar, dass ich einige Remote-Repo-Adressen habe, bei denen ich meine login@password tatsächlich einsetzen musste, damit sie funktionieren. Daher sollten Sie keine lokalen Metadaten (wie .git/config ) angeben, da sie als ... lokal definiert werden sollen.
Tags und Links git