2010-08-18 2 views
5

Mein Anwendungsfall beginnt mit etwas wie this; ein Team verwendet ein zentrales Repository (in meinem Fall ist es Subversion, aber ich glaube, wenn git das Problem wäre das gleiche), und einige der Dateien sind Mitglied-private (Django lokale Einstellungsdateien, IDE private Projekteinstellungen usw.) . Während die private Datei privat bleiben soll - das heißt, ich möchte nicht, dass Änderungen daran vorgenommen werden, um sie zu pushen oder zu committen - möchte ich, dass die Datei verfolgt und versionsgesteuert wird.Wie kann ich Git (oder einigen anderen DVCs) mitteilen, eine Datei privat zu verfolgen?

Die beste Option wäre eine Möglichkeit, die Datei standardmäßig privat zu halten; Ein Workaround wäre eine Möglichkeit, private Commits beizubehalten. Sich daran zu erinnern, die private Datei separat zu übertragen, wäre ein Ärgernis, aber immer noch besser, als überhaupt nicht in der Lage zu sein, sie zu verfolgen.

Im Vergleich zu den vorgeschlagenen Lösungen: this und this sind nicht gut, weil sie verhindern, dass die Datei überhaupt begangen wird; das ist nicht was ich will. Ich möchte es lokal begangen haben; Ich will es nur nicht veröffentlichen.

BTW - während ich DVCSs Liebe, und Git war eine Art von Standard, ich fühle mich nicht besonders dazu verpflichtet (Wortspiel unbeabsichtigt); Wenn nur hg oder bzr dies tun können, könnte es Grund genug für mich sein, zu wechseln.

Antwort

1

Ich würde empfehlen, einen Einstellungsordner und darunter einen Ordner für jeden Benutzer zu haben. Wenn Sie ein anständiges Betriebssystem haben, gibt es eine Umgebungsvariable mit dem Namen des angemeldeten Benutzers.

Ihre Verzeichnisstruktur ist dann:

Project 
/Settings 
/User1 
/User2 
/User3 

Jetzt ist alles eingecheckt und jeder Benutzer hat sein Verzeichnis. Der nächste Schritt besteht darin, den benutzerspezifischen Teil in Ihrem Buildskript, den Projektdateien und den Skripts oder was auch immer zu verwenden, indem Sie die Umgebungsvariable verwenden.

2

Die Art und Weise, wie ich das geschafft habe, und ich weiß nicht, ob dies in Ihrer Situation angenehm wäre, ist eine Vorlagedatei zu erstellen, zB settings.txt.template, die im Committed Repo residierte. und richten Sie dann Ihre persönliche Datei lokal ein (settings.txt wurde zur Datei .gitignore hinzugefügt).

Ansonsten könnten Sie bei git Submodule aussehen http://book.git-scm.com/5_submodules.html

+0

+1 für die Erwähnung Submodule ignorieren entspricht. – sampablokuper

1

Einen schmutzigen hackish Weg, dies zu tun, würde die private Datei unter einem anderen Versionskontrollsystem als Hauptprojektinhalte zu halten sein. Ignorieren Sie beispielsweise die Voreinstellungsdatei in .gitignore, aber erstellen Sie ein Mercurial-Repository in dem Verzeichnis, das alles außer der Voreinstellungsdatei ignoriert. Auf diese Weise können Sie Änderungen in jedem Satz von Dateien verfolgen, aber es wird nicht erlaubt, sie miteinander zu verknüpfen.

1

Vielleicht könnten Sie Ihre Dateien in einem separaten Git-Ordner speichern und einen symbolischen Link verwenden, der .gitigigned ist?

2

Wie wäre es mit einem ignorierten Unterordner mit Benutzereinstellungen? Ähnlich wie bei schoetbi, aber nur ein einzelner Ordner, nicht einer für jeden Benutzer.

/Project 
    /Foo 
    /Bar 
    /Preferences 

in /Project/.gitignore, die Linie /Preferences ignorieren/Projekt/Einstellungen. Und initialisiere ein "geheimes" Repo in/Project/Preferences. (Ich nenne das Geheimnis, weil das äußere Repo davon nichts weiß.) Wenn andere Software ihre Präferenzdateien in einem bestimmten Teil des Hauptrepos erwartet, können Sie einen Symlink zu etwas in den/Project/Preferences erstellen Mappe.Der Symlink könnte verfolgt werden oder nicht; es sollte im Laufe der Zeit stabil sein, so dass Sie sich nicht um seine Geschichte kümmern würden, und seine Geschichte wäre sowieso unabhängig vom Hauptprojekt, also würde ich es wahrscheinlich ignorieren.

Sie brauchen nicht/Preferences unter/Projekt, aber es muss in einer Position relativ zur Symlink Idee/Projekt sein, zu arbeiten, so würde ich es unter halten. Es ist vollkommen in Ordnung, ein Repository unter einem anderen Repository zu initialisieren, solange das äußere Repository das innere ignoriert. Ich mache das mit meinem ~ Ordner und Projekten unter meinem ~ Ordner.

Auch wenn Sie logisch möchten, dass Ihre Benutzereinstellungen mit bestimmten Commits verknüpft sind, die Sie im Hauptrepo gemacht haben, ist dies mit git grundsätzlich unmöglich, also müssen Sie auf jeden Fall eine manuelle Synchronisierung zwischen den Commits durchführen in Ihrem Hauptrepo und den Präferenzen, die zu diesen Commits in Ihrem geheimen Repo gehören. Git kümmert sich grundsätzlich um den Zustand des gesamten Repos (was alles bedeutet, was es verfolgt) und kann niemals ein partielles Commit einreichen. (Weil die SHA-1-Hash-Identität des Commits völlig anders ist, wenn Sie auch nur eine einzige Datei herausnehmen).

0

Oder vielleicht, sagen git Änderungen in dieser Datei zu ignorieren:

git update-index --assume-unchanged <file name> 
0

mine tut dies für git, und wenn Sie eine globale SVN es in der Regel für *_mine_* ignorieren hinzufügen sollte svn gut funktionieren.

Haftungsausschluss: es funktioniert nicht Version standardmäßig, aber Sie werden Backup lassen und alles wiederherstellen, die die *_mine_* Regel

Verwandte Themen