Code gehört mit Hilfe von Versionsverwaltung versioniert und verwaltet – zum Beispiel mit Hilfe von git. Das ist klar. Was ist mit Konfigurationsdateien? Meines Erachtens enthalten die meist auch wesentliche Infos, die versioniert gehören. Wie aber kann ich Config-Files einchecken, wenn der Code (natürlich) selber eingecheckt ist? In einem separatem Repo!

Git hat seine eigene „Verwaltungsinfo“ und eine Kopie des Repos: Beides liegt standardmäßig im Unterverzeichnis .git im Wurzelverzeichnis des ausgecheckten Projekts. Meist liegen Config-Files im selben Verzeichnis. Jedoch kann und möchte ich diese meist nicht zusammen mit dem Code des Projekts einchecken.

Am Beispiel meines aktuellen IoT-Projekts (eigener Artikel kommt…) hier meine Lösung:

Codes des Projekts (öffentlich)

…wird hier verwaltet: https://gitlab.steinkopf.net/iot/temp2thingspeak

✗ git remote -v
origin  https://gitlab.steinkopf.net/iot/temp2thingspeak.git(fetch)
origin  https://gitlab.steinkopf.net/iot/temp2thingspeak.git (push)

Hier habe ich auch ein temp2thingspeak_template.h eingecheckt, welches als Vorlage für ein eigenes temp2thingspeak.h dient und nur Beispiel-Werte enthält.

Config-Files einchecken

Die „richtigen“ Werte der temp2thingspeak.h liegen in einem privaten Repo, das ich so angelegt habe:

• git init --bare .configfiles.git
• git --git-dir=.configfiles.git --work-tree=. remote add origin https...
• git --git-dir=.configfiles.git --work-tree=. add temp2thingspeak.h
• außerdem habe ich mir noch ein readme-config-git.md angelegt, wo ich mir eine „Merkhilfe“ reingeschrieben habe, dass ich hier Config-Files eingecheckt habe, die aber in einem separaten Repository liegen.
• git --git-dir=.configfiles.git --work-tree=. push -u origin --all
• .git/info/exclude: Dies ist quasi ein nicht-eingechecktes gitignore. Hier schreibe .configfiles.git und readme-config-git.md mit rein, damit die nicht beim „normalen“ git status immer als neu hinzugefügt / einzuchecken angezeigt werden.
• .configfiles.git/info/exclude: Umgekehrt sollen im Konfig-Repo die Dateien des Codes nicht als „neu“ erscheinen. Hier kann man der Einfachheit halber z.B. einfach * reinschreiben.

Änderungen am Config-File

Bei Änderungen am Config-File mache ich nun immer folgendes:

git --git-dir=.configfiles.git --work-tree=. commit temp2thingspeak.h
git --git-dir=.configfiles.git --work-tree=. push

Ergebnis

Auf diese Weise bleibt das Code-Repo frei Dateien, die für meine spezielle Installation spefifisch sind. Aber ich kann trotzdem die wertvollen Konfigurations-Infos versioniert pflegen.

Das gleiche Prinzip benutze ich auch bei eigenen Installationen von fremdem, öffentlichem Code. Hier ist es noch offensichtlicher, dass meine Dateien nicht ins allgemeine Repo gehören.

P.S. Mit Hilfe von Branches pflege ich übrigens die Config-Files von mehreren Instanzen des selben Projekts: Jede Instanz hat ihren eigenen Branch im selben Config-Repository.