Wie verwaltet man Konfigurationsdateien bei der Zusammenarbeit?

Question

Ich schreibe ein kurzes Skript mit ein paar einfachen Variablen oben auf der Seite. Ich möchte mit einem Freund daran arbeiten, aber wir sind uns nicht sicher, wie wir die Variablen verwalten sollen, die jedes Mal nach dem Ziehen für einen von uns geändert werden müssen, was unnötigen Müll zum Git-Status hinzufügt. Ich habe darüber nachgedacht, für jeden von uns einen anderen Zweig mit einem anderen Namen zu erstellen, und dann werden für den Master nur Beispielbenutzernamen festgelegt, aber es erscheint mir albern, all diese zusätzliche Arbeit beim Zusammenführen zu machen. Wir könnten die Variablen als Optionen an das Skript übergeben, aber das ist nicht erwünscht, ebenso wenig wie die Ausgliederung in eine andere Konfigurationsdatei. Es wäre toll, so etwas wie eine .gitignore zu haben, aber nur für das Ignorieren von ein paar Zeilen in einer Datei.

Wie lässt sich dies auf elegante Weise bewerkstelligen? Wie wird dieses Problem normalerweise gehandhabt?

Answer 1

Leider können Sie Änderungen an bestimmten Zeilen einer Datei nicht einfach ignorieren, so dass Sie wahrscheinlich auf eine separate Konfigurationsdatei angewiesen sind. Nachfolgend habe ich zwei typische und eine etwas exotischere Methode aufgeführt:

Haben Sie eine Beispielkonfigurationsdatei in git

Hier würden Sie eine Datei aufbewahren config.sample in git als Beispiel, aber die Anwendung würde tatsächlich die Werte in einer Datei verwenden config die sich in .gitignore . Die Anwendung würde dann einen Fehler ausgeben, es sei denn config vorhanden ist. Sie müssen daran denken, die Werte in der Beispieldatei zu ändern, wenn Sie neue Konfigurationsvariablen zu Ihrer persönlichen config Datei. In diesem Fall ist es auch eine gute Idee, Ihre Anwendung überprüfen zu lassen, ob alle erforderlichen Konfigurationsvariablen tatsächlich gesetzt sind, für den Fall, dass jemand vergessen hat, seine config Datei nach Änderungen an der Probe.

Eine Datei mit Standardwerten in git haben

Sie führen eine Datei config.defaults in git, die möglichst sinnvolle Standardkonfigurationswerte hat. Ihre Anwendung bezieht die Konfiguration zunächst von config.defaults und dann von config (die sich in .gitignore ), um möglicherweise einen der Standardwerte zu überschreiben. Mit dieser Methode würden Sie normalerweise keinen Fehler für config nicht zu existieren, so dass die Anwendung für Personen, die sich nicht die Mühe gemacht haben, eine Datenbank zu erstellen, sofort funktionieren kann. config .

Verwendung einer einzigen Konfigurationsdatei mit --assume-unchanged

Eine dritte Möglichkeit, die ich persönlich in diesem Fall nicht empfehlen würde, wäre, eine einzige Konfigurationsdatei zu haben, die in Git übertragen wird, aber mit git update-index --assume-unchanged <FILE> , um git anzuweisen, Änderungen daran zu ignorieren. (Dies wird weiter beschrieben in diesen nützlichen Blogbeitrag .) Das bedeutet, dass Ihre lokalen Änderungen an der Konfigurationsdatei nicht mit git commit -a oder tauchen Sie auf in git status .

Answer 2

Die Python/Django-spezifische Lösung besteht darin, eine gemeinsame settings.py Dateien, die in das Repository eingecheckt werden, und eine lokale settings_local.py importiert am Ende von settings.py die einige der Einstellungen mit maschinenspezifischen Werten überschreibt.

Answer 3

In meinem Fall habe ich "Config"-Variablen in einer separaten (kleinen) Datei, wie alle anderen Entwickler im Team auch. Dinge wie der Standort meiner Datenbank usw. werden dort gespeichert. Wir setzen den Namen dieser Datei in unsere .gitignore damit sie nicht versionskontrolliert ist, sondern eine "sample_config"-Datei eincheckt, damit Neulinge eine Kopie davon machen und sie für ihre eigenen Zwecke verwenden können.

Answer 4

Andere Optionen (nicht elegant, aber möglicherweise hilfreich):

• Utilisez git stash y git stash pop für Ihre Konfigurationsdatei
• Eine Zweigstelle mit dem Namen, sagen wir, Konfiguration mit den Änderungen Ihrer lokalen Konfigurationsdatei und verwenden Sie dann git checkout config <your config file>

Die zweite Option ist gut, wenn Sie die lokalen Konfigurationsänderungen in der Repo (irgendwo) aufbewahren müssen.

Answer 5

Ich habe einige kurze Skripte dieser Art, und anstatt eine separate Konfigurationsdatei zu erstellen, erstelle ich eine separate Datei setenv.sh (oder setenv.bat). Ich verschiebe die wenigen, einfachen Variablen in diese neue Datei und rufe die Datei setenv.sh im Hauptskript auf. Variablen, die sich pro Benutzer nicht ändern, bleiben im Hauptskript. Je nachdem, wie klein dieses setenv.sh-Skript ist, werde ich entweder eine Dokumentation schreiben, wie man dieses setenv.sh erstellt, oder ein setenv.sh-Beispiel als Vorlage verwenden.

Eine Variante davon ist, keine setenv.sh zu erstellen oder aufzurufen und den Benutzer die im Hauptskript verwendeten Umgebungsvariablen setzen zu lassen. Das Hauptskript wird sich beschweren, wenn die Variablen nicht vorhanden sind.

Einige kurze Skripte entwickeln sich zu großen Skripten oder werden zu vollwertigen Anwendungen. Wenn das passiert, gehe ich den Weg der Konfigurationsdateien. Wir haben eine Anwendung, die Konfigurationsdateien verwaltet und Config heißt, unter http://www.configapp.com . Config verfügt über das Konzept der Umgebungen und Instanzen. In Ihrem Beispiel haben Sie 1 lokale Umgebung und 2 Instanzen. Allgemeine Variablen gehören in die lokale Umgebung und maschinenspezifische Variablen (Sie und Ihr Freund) gehören in die Instanzen. Das ist etwas zu viel für kleine Skripte, funktioniert aber gut für Anwendungen.