Das Git-Projekt hat am 4. Januar 2016 die Version 2.7 veröffentlicht. Die offiziellen Release Notes nennen neue Befehle für die Arbeit mit Remotes und Worktrees sowie Verbesserungen an Gitk, Rebase und Bisect. Für Teams aus der Spieleentwicklung bleibt Git damit ein Werkzeug, das den täglichen Umgang mit Quellcode und Build-Projekten erweitert.
Git 2.7 ergänzt Befehle für Remotes und Worktrees
Mit Git 2.7 zeigt der neue Unterbefehl git remote get-url die für einen Remote hinterlegte Abruf- und Push-Adresse an. git worktree list gibt eine Übersicht der zusätzlichen Arbeitsverzeichnisse aus. Auch die Fehlersuche in getrennten Worktrees wurde ausgebaut: Git führt die Referenzen einer git bisect-Sitzung nun pro Worktree, sodass unabhängige Tests parallel möglich sind.
Für Rebase-Vorgänge kommt git rebase --no-autostash hinzu. Damit lässt sich eine konfigurierte automatische Ablage temporärer Änderungen direkt für einen einzelnen Aufruf abschalten. Das ist vor allem bei reproduzierbaren Arbeitsabläufen hilfreich, wenn ein Build oder ein Testlauf exakt auf dem aktuellen Arbeitsstand beginnen soll.
Verbesserungen bei Debugging und Build-Abläufen
Die Release Notes führen außerdem eine überarbeitete Darstellung von Gitk auf hochauflösenden Monitoren auf. Git Bisect kann bei der Suche nach einer Zustandsänderung nun eigene Begriffe wie old und new verwenden. Für große Repositories verbessert Git 2.7 zudem den Umgang mit Git LFS in git p4 und erweitert die Konfiguration für rekursive Submodule bei git push.
Das Projekt bereitete mit der Version außerdem weitere Änderungen an der internen Repository-Darstellung vor. Eine neue Formatversion mit Erweiterungsmechanismus sollte spätere Anpassungen am Speicherformat ermöglichen. Für die Arbeit an umfangreichen Spielprojekten ist dabei entscheidend, dass die bestehenden Arbeitskopien und Automatisierungen weiter verlässlich funktionieren.
Git bleibt Bestandteil moderner Spieleentwicklung
Git 2.7 brachte keine einzelne Funktion speziell für Spieleengines mit. Die Änderungen betreffen jedoch typische Abläufe technischer Teams: parallele Arbeitskopien, reproduzierbare Tests, Fehlersuche und die Verwaltung großer Quellcodebestände. Ein früherer Beitrag zu GitLab 8 zeigt, wie eng Versionsverwaltung und automatisierte Builds bereits 2015 zusammenrückten.