Das verteilte Versionsverwaltungssystem Git 2.54 ist erschienen. Ein experimenteller git history-Befehl und ein veränderter Umgang mit Hooks zählen zu den wichtigsten Neuerungen in dem Release, an dem 137 Personen mitgewirkt haben.

Commit-Historie verändern mit git history

Wie GitHub in einem Blogeintrag ausführt, bot Git bisher bereits Möglichkeiten, die Historie eines Projekts zu verändern. So lassen sich mit git rebase -i Commits anders anordnen, editieren oder verwerfen. Das ändert jedoch auch Working Tree und Index, was weitreichende Aktionen nach sich ziehen kann.

Für einfache Fälle steht daher nun der experimentelle Befehl git history bereit, der unter der Haube auf der Funktionsweise von git replay basiert. git history unterstützt die beiden Vorgänge reword und split. Mit git history reword können Entwicklerinnen und Entwickler eine Commit-Nachricht im Editor öffnen und anpassen, um zum Beispiel einen Tippfehler zu berichtigen. Das aktualisiert ebenfalls Branches, die aus diesem Commit hervorgehen. Im Gegensatz zu git rebase verändern sich Working Tree und Index hierbei jedoch nicht. Die zweite mögliche Aktion, git history split , erlaubt das Aufteilen eines Commits in zwei verschiedene Commits.

Zu den bewussten Einschränkungen des history-Befehls zählt, dass er weder mit Historien umgehen kann, die Merge Commits enthalten, noch Vorgänge durchführt, die Merge-Konflikte auslösen würden.

Flexiblere Hook-Definition

Eine weitere bedeutende Neuerung betrifft den Umgang mit Git-Hooks. Diese ließen sich bisher nur als ausführbare Skripte definieren, die sich in einem spezifischen Verzeichnis befanden – standardmäßig im Unterverzeichnis hooks des .git-Verzeichnisses. Das brachte einige Schwierigkeiten mit sich, wie GitHub erläutert: Wollten Entwickler beispielsweise vor jedem Commit auf allen Repositories einen Linter laufen lassen, so mussten sie das entsprechende Skript in jedes Repository kopieren, was zu Arbeitsaufwand und Fehleranfälligkeit führte.

Diese Probleme soll Git 2.54 lösen, denn Hooks lassen sich nun in den Konfigurationsdateien definieren. Statt ein Skript in .git/hooks/pre-commit zu platzieren, ist nun diese Alternative möglich:

[hook "linter"]
   event = pre-commit
   command = ~/bin/linter --cpp20

Auf diese Weise lassen sich Hooks zentral definieren und auf alle Repos anwenden. Eine solche Konfiguration kann sich User-basiert in ~/.gitconfig befinden, systemweit in /etc/gitconfig oder in einer lokalen Konfigurationsdatei eines Repositories. Entwicklerinnen und Entwickler können zudem mehrere Hooks für ein bestimmtes Event definieren oder Hooks wahlweise in einem Repository deaktivieren.

Weitere Informationen zu diesen und anderen Neuerungen in Git 2.54 finden sich in den Release Notes.

(mai)

In dieser Episode spricht Richard Seidl mit Holger Santelmann über IT-Sicherheit in Entwicklungsprozessen und über die internationale Norm IEC 62443-4-1, die festlegt, wie sichere Entwicklungsprozesse für industrielle Software und Systeme gestaltet werden sollen. Im Zentrum steht die Frage, wie Normen praktisch umgesetzt werden können, ohne dass sie nur lästige Pflicht bleiben. Holger Santelmann erzählt, wie sein Unternehmen diese Norm eingeführt und zum echten Werkzeug für bessere Softwarequalität gemacht hat. Es geht um konkrete Herausforderungen: von Trainings und unabhängigen Testern bis hin zu interner Reflexion und Zusammenarbeit im Team.

Holger Santelmann ist Dipl.-Medieninformatiker (FH) und verfügt über mehr als 20 Jahre Erfahrung in der Softwareentwicklung. Er hat als Senior Software Developer bei der Firma M&M Software GmbH angefangen und sich in den letzten Jahren immer mehr auf das Thema Release- bzw. Testmanagement spezialisiert. Als Leiter des Competence Centers Quality Engineering treibt er das Thema Qualitätssicherung innerhalb der Firma M&M Software GmbH weiter voran und unterstützt den Softwareentwicklungsprozess.

Software-Testing im Gespräch

Bei diesem Format dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Praxisnah sicher entwickeln mit IEC 62443-4-1 – Holger Santelmann“.

(mdo)

Google soll intern ein Sonderteam aus Forschern und Ingenieuren zusammengestellt haben, um seine KI-Modelle für die Softwareentwicklung zu verbessern. Auslöser ist laut einem Bericht von The Information die wachsende Überzeugung innerhalb von Google DeepMind, dass Anthropics Coding-Tools den eigenen Gemini-Modellen derzeit überlegen sind. Während Anthropic nach eigenen Angaben nahezu seinen gesamten Code KI-gestützt schreibt, liegt der Anteil bei Google laut Finanzchefin Anat Ashkenazi bei rund 50 Prozent. Der Rückstand soll nun aufgeholt werden – und zwar nicht nur aus Wettbewerbsgründen: Googles Mitgründer Sergey Brin sieht verbesserte Coding-Fähigkeiten als Zwischenschritt auf dem Weg zu einer KI, die sich irgendwann selbst weiterentwickeln kann.

Mit seinem „Strike Team“ verschärft damit auch Google die Gangart in dem zurzeit meist umkämpften Teilbereich der Künstlichen Intelligenz. Anthropic hatte sich mit seinem Coding-Tool Claude Code frühzeitig auf den Bereich Coding spezialisiert. OpenAI hat sein Engagement rund um das KI-Tool Codex massiv erweitert, woraufhin Anthropic auch ein Design-Tool namens Claude Design vorstellte.

Google will internen KI-Einsatz erhöhen

Bei Google geht es aktuell erst einmal auch darum, den internen Einsatz von KI stärker voranzubringen, wie das US-Magazin The Information unter Berufung auf namentlich nicht genannte Quellen im Unternehmen berichtet. Bislang habe sich Google bei seinen Modellen vor allem auf die Bedürfnisse externer Kunden konzentriert. Ähnliches gilt für Apple: Auch dort werden Entwickler gerade im Umgang mit KI-Coding-Tools für die Softwareentwicklung geschult, um den internen Einsatz zu modernisieren. Solche internen Modelle, welche die Eigenheiten des Google-Codes besser abbilden als öffentliche Modelle, wolle man zwar wegen der darin enthaltenen Geschäftsgeheimnisse nicht nach außen geben. Sie können aber eine wichtige Zwischenstufe sein, um bessere öffentliche Modelle zu erschaffen.

Teamleiter sei Sebastian Borgeaud, ehemaliger Pre-Training-Lead für Gemini bei Google DeepMind. Der Fokus liege auf komplexen Langzeit-Coding-Aufgaben. Dazu zähle das Verständnis von Codebases und das Schreiben kompletter Software. Google-Mitgründer Sergey Brin und DeepMind-CTO Koray Kavukcuoglu sollen persönlich in das Strike Team eingebunden sein. Brin habe die Mitarbeiter angehalten, verpflichtend interne Agenten für mehrstufige Aufgaben zu nutzen. Ein Fernziel sei der sogenannte „AI Takeoff“, also eine KI, die sich selbst verbessern kann. Die Nutzung der Coding-Tools werde intern mit einem Leaderboard nachgehalten.

Fernziel: Eine KI, die sich selbst verbessert

Dabei treffen Googles Ambitionen auf eine Branche, die KI-Tools bereits weit verbreitet einsetzt. Das Entwicklerportal Stack Overflow fand in seiner jährlichen Befragung mit 49.000 Teilnehmern heraus, dass 84 Prozent der Entwickler entsprechende Tools schon nutzen oder zumindest deren Einsatz planen. Sie versprechen sich damit vor allem eine Zeitersparnis. Bislang, so ergeben Befragungen, sei diese Hoffnung aber nicht immer erfüllt worden. 46 Prozent der Entwickler misstrauen der Genauigkeit von KI-Tools.

(mki)