Git: Langfristiges Archivieren eines verwendeten Standes

[Faluröd]

Hallo zusammen!
Ich habe eine Frage, die insbesondere für alle Git-Tüftler interessant ist. Motivation ist folgende: Wir verwenden Git, um bestimmte Programme von uns zu verwalten. Wegen Archivierbarkeit wollen wir bei jeder produktiver Anwendung des Programms mit dokumentieren, mit welchem Code / welcher Programmversion die Berechnung ausgeführt wurde.

Der erste Gedanke ist klar: Wir speichern die Commit ID, denn deren Zweck ist ja genau, jeder Version einen Namen zu geben. Aber wir haben dann etwas weiter diskutiert, und sind leider auf etliche Fälle gekommen, bei denen die Commit ID nicht aussagekräftig ist: Der Nutzer könnte Skripte z.B. ändern, aber es gibt keinen Commit dieser Änderungen. Oder er könnte einen Feature-Branch nehmen, den es nur lokal gibt. Oder es ist ein temporäres Feature, was verworfen wird und dann der Branch irgendwann aufgeräumt wird. Lange Reder kurzer Sinn: Wir müssen mehr machen als einfach nur die Commit ID speichern.

Deswegen ist meine Frage: Was muss ich alles prüfen, damit die Git ID wirklich sicher ist? Also es kein Schlupfloch gibt, dass der real verwendete Code sich von dem unterscheidet, wenn ich diese ID vom Server auschecke.

Mein aktueller Entwurf wären im Kern folgende Git-Befehle. Die sind eingebettet in ein Skript, welches die Ausgaben der Git-Befehle weiter prüft.

git branch --show-current
git diff origin/myCurrentBranch
git describe --exact-match
git log -1 –format=%H

Zu den einzelnen Zeilen:

1. Hier greife ich den Namen des aktuell ausgecheckten Branches ab. Brauche ich zum einen für die 2. Zeile. Zum anderen hätte ich gesagt: Der Nutzer darf nur den Master- oder Development-Branch nutzen. Denn bei allen anderen kann passieren, dass diese gelöscht werden
2. Damit möchte ich den aktuellen Stand des Git-Repos mit der letzten vom Server gepullten Version des aktuellen Branches vergleichen. Sind diese 1:1 gleich, dann ist die Rückgabe leer. Hat der Nutzer was geändert (egal ob unstaged, staged oder lokaler Commit ohne Push), dann ist die Rückgabe nicht leer. Das wäre auch der Fall, wenn es origin/myCurrentBranch gar nicht gibt, was zusätzlich zu Schritt 1 absichert, dass der Nutzer nur auf erlaubten Branches unterwegs ist.
3. Mit der Zeile möchte ich den Git-Tag des aktuell ausgecheckten Standes abfragen. Das prüfe ich dann per Regexp, ob es dem typischen Muster unserer produktiv gekennzeichneten Versionen entspricht. Diese Tags sind geschützt, denn die dürfen nur Reviewer setzen, normale Nutzer jedoch nicht.
4. Damit hole ich die Commit-ID der aktuell ausgecheckten Version.

Soweit ich das sehe, sollte ich mit Schritten 1+2 die notwendigen Informationen von Git bekommen, dass der aktuell verwendete Dateistand 1:1 ist wie auf dem Server? Und dann mit Schritt 3+4 dann per Tag + Commit-ID dieses Standes die notwendigen Infos erhalten, die wir bei jeder zu archivierender Anwendung mit dokumentieren müssen?

Danke euch schon mal fürs Mitdenken! Seid da gerne kreativ, welche Misuse-Fälle man alles mit Git-Repos machen kann, sodass man den Dateistand nicht mal eben rekonstruieren kann.

 

[JumpingCat]

git verwaltet (Quell)Code und keine (binary blohs) Programme. Wenn du die kompilierten Programme verwalten willst, dann das sind Artefakte und da gibt es kostenpflichtige Software wie Artifactory oder auch diverse OpebSource.

Du suchst eher reproduzierbare Builds?

Ich denke das Thema "jemand hat Code ausgecheckt, manuell modifiziert, etc" kannst du eigentlich nie abfangen.

Du kannst auch einführen nur auf einem Server wie Jenkins / Azure DevOps zu kompilieren und dann immer alle Artefakte zu archivieren. Das gehört in die Build Pipeline mit rein.

Das was du eigentlich immer machst, ist dann die Binary den Code Stand wie Version, Tag oder sogar git commit dran schreibst.

 

[Faluröd]

Es geht in dem Fall um Matlab-Skripte. Da gibt es keine kompilierte Version, deswegen eben der Weg über den Git-Stand.

 

[JumpingCat]

Dann könntest du nur noch Skripte ausführen die aus dem Git deployed werden und den Personen direkten Zugriff auf Matlab verbieten. Falls Matlab so eine Arbeitsweise erlaubt.

 

[Tobias0]

Wir speichern die Commit ID, denn deren Zweck ist ja genau, jeder Version einen Namen zu geben. Aber wir haben dann etwas weiter diskutiert, und sind leider auf etliche Fälle gekommen, bei denen die Commit ID nicht aussagekräftig ist:

Das kann gar nicht sein, weil die commit id u. a. anhand der aktuellen Änderung, die committet wird, berechnet wird (die parent id fließt auch mit ein, quasi eine Blockchain).

Git verwendet Sha1 Sums und die kannst du auch für die Integrität eurer Scripte verwenden: https://stackoverflow.com/questions/35430584/how-is-the-git-hash-calculated

 

[Tornhoof]

Deswegen ist meine Frage: Was muss ich alles prüfen, damit die Git ID wirklich sicher ist? Also es kein Schlupfloch gibt, dass der real verwendete Code sich von dem unterscheidet, wenn ich diese ID vom Server auschecke.

Dafür ist git nicht gedacht, du brauchst ja was mit non-repudiation, authentication und so. Google einfach mal nach Git und non-repudiation.
Du brauchst Minimum zusätzlich einen Audittrail der die notwendigen Kriterien erfüllt.

 

[Hancock]

Wie wäre es mit

git describe --always --candidates=1 --broken

Wer zu faul ist, seine Änderungen wohin zu commiten, der soll auch dirty bleiben.

Git an sich ist aber nur ein Programm, wer will kann es aushebeln.

 

[Tobias0]

Git an sich ist aber nur ein Programm, wer will kann es aushebeln.

Git kann man nicht aushebeln. Aber so, wie ich das verstanden hatte, werden die Änderungen nicht committet, gepusht und dann remote ausgeführt, sondern alles lokal. Das kannst du selbstverständlich nicht sicher machen.

 

[JumpingCat]

Da ist an sich kein technisches Problem mehr. Wenn die Leute sich nicht an Arbeitsanweisungen halten, dann ist das erst ein Thema für den Chef. Letzte Stufe ist die Personalabteilung mit einer Abmahnung. So eine Baustelle ist nicht durch die IT lösbar.

 

[Faluröd]

Ich muss wohl noch ein paar Informationen zum Hintergrund meiner Frage geben. Wir entwickeln keine Software, die nach draußen geht. Das Stichwort Automatisierungsskripten für interne Zwecke trifft es viel besser. Denn unsere Arbeitsabläufe als Berechnungsingenieure haben etliche repetitive Aufgaben. Die Skripte sind also ein Hilfsmittel für uns, dass wir weniger Arbeitszeit mit stupiden Klicken verbringen und damit mehr Zeit für unsere eigentlichen Ingenieursfragen haben.

Weiterhin liegt es in der Natur dieser Aufgaben, dass die Nutzer Daten vom Schritt 1 auswerten, beurteilen, damit Schritt 2 anstoßen, und dann nach ein paar Schritten zur Lösung kommen. Jede dieser manuellen Übergaben ist per se ein Schlupfloch, an denen Daten manipuliert werden könnten. Und nein, die monolithische Software, die alles in einem Schritt erledigt, gibt es nicht. Die Schlupflöcher wird es immer in irgendeinen Umfang geben.

Also zurück zu meiner Frage: In dem geschilderten Umfeld bringt es meiner Meinung nach nicht allzu viel, das Thema "niet- und nagelfeste Dokumentation der Skripte" überzubetonen. Dennoch würde es mich stark überraschen, wenn es nicht mittels ein paar einfacher Git-Befehle möglich ist, schon mal vieles auszuschließen, was passieren kann (wie eine nicht gepushte Version der Skripte).

Den Hinweis von @Hancock nehm ich auf alle Fälle auf. Die --broken-Option von git describe kannte ich bisher nicht, die erlaubt einen guten Rückschlüss auf den Zustand des Git-Repos.