Die vielfältigen Fähigkeiten von Git, Teil 1
Im normalen Entwickleralltag nutzt man die Standardmöglichkeiten von Git. Aber gelegentlich können selten genutzte Fähigkeiten das Leben angenehmer machen – wenn man sie denn kennt.
(Bild:
- Andreas Krüger
Wie ein roter Faden durchzieht "Vielfachheit" die Fähigkeiten, die der folgende Artikel vorstellt. Damit ist gemeint, dass von einem Repository aus "mehrere" verwalten werden können, wo im normalen Alltag meistens "eins" genügt. Beispiele gefällig? Man nutzt im Normalfall nur einen Worktree (Verzeichnisbaum) auf der eigenen Festplatte, ein Remote-Repository "origin" und einen Versionsgraphen im lokalen Repository.
Im Folgenden kommen Situationen zur Sprache, in denen mehrere Arbeitsverzeichnisse, mehrere Remotes und mehrere Versionsbäume nützlich sind.
Mehrere Arbeitsverzeichnisse
Eine solche Situation ist die Unterbrechung. Irgendetwas schiebt sich in der Dringlichkeit nach vorne. Was man gerade getan hat, muss unterbrochen werden und warten. Ein klassisches Beispiel aus der DevOps-Praxis: Man entwickelt an einem Feature-Branch. Plötzlich hängt etwas in der CI/CD-Pipeline und ist im master zu fixen, und zwar schnell.
Es gibt mehrere Möglichkeiten, mit einer solchen Situation umzugehen. Beispielsweise kann man git stash benutzen, um den Feature-Branch-Zustand zu sichern. Dann wechselt man vom Feature-Branch zum master und nimmt die Arbeit am CI/CD-Problem auf.
Eine andere, probate Möglichkeit bietet sich dadurch, dass ein Git-Respository auf der lokalen Festplatte mehr als ein Arbeitsverzeichnis ("Worktree") verwalten kann.
Man erzeugt so ein zweites Arbeitsverzeichnis aus der Wurzel des ersten heraus, zum Beispiel mit
git worktree add ../worktree2 master
Nun kann man mit einem schlichten cd ../worktree2 in das erzeugte Arbeitsverzeichnis wechseln, in dem master bereits ausgecheckt ist, und mit cd wieder zurück ins ursprüngliche mit dem Feature-Branch. Überhaupt ermöglichen multiple Arbeitsverzeichnisse bequeme und schnelle Kontextwechsel. Zwei IDE-Instanzen können parallel laufen, man braucht bei Bedarf nur zwischen den Fenstern zu wechseln.
In der geschilderten Beispielsituation, dass an der CI/CD-Pipeline etwas repariert werden muss, kann das sehr angenehm sein: Während der CI/CD-Job erst losläuft, hat man schon wieder die Arbeit am Feature-Branch aufgenommen.
Intern hat worktree2 in seinem Verwaltungsverzeichnis .git nur eine Art Verweis auf das eigentliche Repository. Dadurch stehen alle Commits, Branches, Remotes usw. in beiden gleichartig zur Verfügung. Man kann zum Beispiel in einem Arbeitsverzeichnis einen Commit zu einem Branch hinzufügen und ihn in einem zweiten Arbeitsverzeichnis in einen anderen Branch hineinmergen.
Den Index gibt es naturgemäß für jeden Worktree einzeln. So bleiben die verschiedenengit add-Befehle unabhängig voneinander. Übrigens wehrt sich Git dagegen, den selben Branch in zwei verschiedenen Arbeitsverzeichnissen auszuchecken.
Wer das Arbeiten mit parallelen Arbeitsverzeichnissen für sich entdeckt hat, mag vielleicht gleich beim Anlegen eines neuen Feature-Branches für diesen ein eigenes Arbeitsverzeichnis vorsehen. Dafür bietet git add worktreeeine ähnliche Funktionsweise -b new_branch wie git checkout. Man nutzt sie zum Beispiel wie folgt:
git fetch origin
git worktree add -b f_branch ../f_branch_worktree origin/master
Ein solches Arbeitsverzeichnis lässt sich wieder abräumen, zum Beispiel mit folgender Zeile:
git worktree remove ../f_branch_worktree
Die Arbeit mit mehreren Worktrees hat sich in der alltäglichen Praxis des Autors bewährt. Allerdings warnt die Dokumentation derzeit, dass das Feature von Git noch experimentell ist, und rät insbesondere davon ab, von Repositorys mit Submodulen mehrere Arbeitsverzeichnisse zu generieren.
