Einführung
Eine Datei kann auf deinem Rechner nützlich und trotzdem für einen Quellcode-Commit ungeeignet sein. Dieses neue DeskLite-Repository enthält eine kleine Geschäftsänderung und eine private Konfiguration mit fiktiven Zugangsdaten. Die private Datei wurde versehentlich vorgemerkt, aber noch nie committet.
Du lernst das Git-Arbeitsverzeichnis, den Staging-Bereich und den Commit-Schnappschuss kennen. Du trennst private Einstellungen von auszuliefernden Beispielen und verwendest einen vorbereiteten Scanner für Zugangsdaten. Du benötigst weder ein Git-Konto noch ein entferntes Repository oder Git-Vorkenntnisse.
Arbeitsverzeichnis und Staging-Bereich finden
In diesem Schritt stellst du fest, welche Dateien Git zum Speichern vorbereitet.
Git zeichnet ausgewählte Dateiversionen in einem Repository auf. Sein Arbeitsverzeichnis enthält die Dateien, die du bearbeitest. Der Staging-Bereich hält den nächsten Schnappschuss bereit, den du committen möchtest. Ein Commit speichert diesen vorgemerkten Schnappschuss in der lokalen Historie; er lädt nicht automatisch etwas hoch.
cd /home/labex/project/desklite-git
git status vergleicht diese Bereiche:
git status
Das vorbereitete Terminal zeigt Dateikategorien möglicherweise farbig an; entscheidend ist die Formulierung. Achte auf zwei unterschiedliche Kategorien. private.env erscheint unter den zum Commit vorgemerkten Änderungen: Ihr Inhalt ist bereits im Staging-Bereich. service/app.py erscheint unter den nicht zum Commit vorgemerkten Änderungen: Ihre Geschäftsänderung liegt bisher nur im Arbeitsverzeichnis. Der Branchname kann variieren und hat keinen Einfluss auf diese Aufgabe.
git ls-files listet verfolgte Pfade auf, einschließlich neuer Dateien, die für ihren ersten Commit vorgemerkt wurden:
git ls-files
Die private Datei erscheint, obwohl sie noch nicht committet wurde. Jetzt ist der richtige Zeitpunkt, um ein Datenleck zu verhindern. Die ursprüngliche Commit-Historie ist sauber. Erstelle noch keinen Commit: Prüfe zuerst, was darin enthalten wäre.
Die beiden Änderungsarten vergleichen
In diesem Schritt vergleichst du die Geschäftsänderung mit der vorgemerkten privaten Konfiguration.
git --no-pager diff zeigt nicht vorgemerkte Änderungen. Die globale Option --no-pager hält die Ausgabe direkt im Terminal, sodass kein separates Anzeigeprogramm geschlossen werden muss. Beschränke sie durch Angabe des Pfades auf die Geschäftsdatei:
git --no-pager diff service/app.py
Zeilen mit - am Anfang zeigen alten Inhalt, Zeilen mit + neuen Inhalt. Das neue Programm gibt DeskLite tickets ready aus. Behalte diese beabsichtigte Geschäftsänderung bei.
git --no-pager diff --cached zeigt stattdessen vorgemerkte Inhalte. Die Option --cached wählt den Staging-Bereich aus:
git --no-pager diff --cached
Du solltest private.env und ihre Schlüssel SERVICE_NAME und API_TOKEN sehen. Das Token ist fiktiv und funktioniert nirgendwo außerhalb dieses Kurses. Trotzdem steht es für die Art von Wert, die privat bleiben sollte.
Ein vorgemerkter Schnappschuss kann von der aktuell auf dem Datenträger vorhandenen Datei abweichen. Wer nur das Arbeitsverzeichnis prüft, kann daher etwas übersehen, das bereits für einen Commit vorbereitet ist. Untersuche vor dem Commit beide Änderungsarten.
Im Repository ist bereits eine lokale Beispielidentität als Autor konfiguriert. Du gibst keine persönlichen Daten an und verbindest Git nicht mit einem externen Dienst.
Einen maskierten Zugangsdatenfund lesen
In diesem Schritt führst du den vorbereiteten Scanner für die private Datei aus und interpretierst den Fund.
Gitleaks erkennt Textmuster, die mit Zugangsdaten verbunden sind. Der Kursstarter course-secrets führt Gitleaks 8.24.2 mit einer festen lokalen Regel für unser synthetisches Tokenformat labex_ aus. Er maskiert gefundene Werte und sendet keine Netzwerkanfragen. Diese begrenzte Kursregel ist keine vollständige Regelung zur Erkennung von Geheimnissen im Produktivbetrieb.
Übergib dem Starter eine Datei oder ein Verzeichnis, um den aktuellen Inhalt zu prüfen:
course-secrets private.env
Erwartet wird ein Fund mit der Kennung desklite-practice-token, einem Dateinamen/einer Zeilennummer und einem maskierten Geheimnis. Der Befehl endet absichtlich mit Status 1, weil er Zugangsdaten gefunden hat. Ein Fund ist etwas anderes als ein Werkzeug, das nicht ausgeführt werden kann.
Dieser Befehl prüft die aktuelle Datei unabhängig davon, ob Git sie verfolgt. Eine später eingeführte Historienprüfung untersucht committete Änderungen. Eine saubere Historie würde diese noch nicht committete Datei nicht sicher für das Vormerken machen.
Der private Wert liegt hier nur in vorgemerkten Inhalten beziehungsweise im Arbeitsverzeichnis. Wären echte Zugangsdaten bereits offengelegt worden, würde ihre Entfernung aus einem neuen Commit sie weder ungültig machen noch alte Kopien löschen: Ihr Eigentümer müsste sie widerrufen oder ersetzen. Diese Übung behandelt kein Umschreiben der Historie.
Private Einstellungen vom Beispiel trennen
In diesem Schritt entfernst du private Einstellungen aus der Git-Versionsverfolgung, ergänzt eine eng begrenzte Ignorierregel und erstellst ein verwendbares öffentliches Beispiel.
git rm --cached entfernt einen Pfad aus dem Staging-/Verfolgungsbereich und erhält dabei die lokale Datei. Hier macht es das versehentliche Vormerken einer neuen privaten Datei rückgängig:
git rm --cached private.env
Öffne .gitignore. Diese Datei teilt Git mit, welche nicht verfolgten Pfade ausgelassen werden sollen:
nano .gitignore
Gib diese einzelne Regel ein und speichere anschließend mit Ctrl+O, Enter, Ctrl+X:
/private.env
Das führende / verankert die Regel im Stammverzeichnis dieses Repositorys. Ignoriere nicht service/: Es enthält Dateien, die ausgeliefert werden sollen. Ignorierregeln entfernen weder bereits verfolgte Dateien noch alte Commits automatisch; deshalb war der vorherige Befehl notwendig.
Erstelle ein öffentliches Beispiel mit denselben Konfigurationsschlüsseln:
nano service/config.example.env
Speichere:
SERVICE_NAME=DeskLite
API_TOKEN=REPLACE_ME
Das Beispiel zeigt einem zukünftigen Bediener, welche Einstellungen benötigt werden, ohne gültige Zugangsdaten bereitzustellen. Behalte die ursprüngliche private Datei lokal.
ls private.env
git status
Der private Pfad sollte weder vorgemerkt sein noch als nicht verfolgt aufgelistet werden. .gitignore und das öffentliche Beispiel sollten nicht verfolgt und bereit zum gezielten Vormerken sein. Die vorhandene Geschäftsänderung bleibt nicht vorgemerkt.
Nur die Auslieferungsdateien vormerken
In diesem Schritt bereitest du genau die Dateien vor, die für den nächsten Commit vorgesehen sind.
git add kopiert den aktuellen Inhalt benannter Pfade in den Staging-Bereich. Gib jede vorgesehene Auslieferungsdatei ausdrücklich an:
git add service/app.py service/config.example.env .gitignore
Prüfe sowohl die Dateikategorien als auch den vorgemerkten Inhalt:
git status
git --no-pager diff --cached
Erwartet werden genau die beabsichtigte Geschäftsänderung, die eng begrenzte Ignorierregel und das sichere Beispiel. Es darf kein privates Token enthalten sein. Falls du eine Datei nach git add erneut bearbeitest, musst du den aktualisierten Inhalt vor dem Commit wieder vormerken; Git ersetzt einen zuvor vorgemerkten Schnappschuss nicht automatisch.
Liste die verfolgten Pfade erneut auf:
git ls-files
Die drei Auslieferungspfade sollten erscheinen, private.env dagegen nicht. Diese Prüfung beantwortet eine andere Frage als ls: Die lokale private Datei existiert weiterhin, liegt aber außerhalb der Git-Versionsverfolgung.
Der nächste Schritt prüft das auszuliefernde Verzeichnis. Die Prüfung eines bewusst begrenzten Auslieferungsumfangs weist nicht nach, dass jede andere Datei auf dem Rechner frei von Geheimnissen ist.
Den Auslieferungsinhalt prüfen
In diesem Schritt prüfst du das auszuliefernde Quellverzeichnis und behältst dabei die privaten lokalen Einstellungen.
Führe denselben Scanner mit fester Regel für das Verzeichnis service aus:
course-secrets service
Erwartet werden no leaks found und ein erfolgreicher Exit-Status. Der Scanner verarbeitet die tatsächlichen Quellcode- und Beispielinhalte. Er verlässt sich nicht auf einen manuell bearbeiteten Bericht.
Die private Konfiguration liegt im Stammverzeichnis des Repositorys, außerhalb dieses Auslieferungsverzeichnisses. Eine erneute Prüfung dieser privaten Datei würde weiterhin ihr Token melden; das ist zu erwarten. Wir haben die Zielgruppen getrennt, ohne zu behaupten, dass sensible Daten nicht mehr existieren.
Untersuche den vorgemerkten Schnappschuss noch einmal:
git --no-pager diff --cached
Die Verzeichnisprüfung untersucht aktuelle Dateien; der Diff prüft, was Git speichern wird. Beide müssen mit dem beabsichtigten Auslieferungsinhalt übereinstimmen. Eine Prüfung ohne Funde macht nur eine Aussage zur konfigurierten Regel und zum geprüften Umfang – sie kann nicht nachweisen, dass sämtliche möglichen Geheimnisse oder Sicherheitslücken fehlen.
Du hast jetzt einen geprüften vorgemerkten Schnappschuss. Der nächste Schritt speichert ihn als lokalen Commit.
Einen lokalen Commit speichern
In diesem Schritt speicherst du den geprüften vorgemerkten Schnappschuss in der lokalen Historie.
git commit zeichnet den Staging-Bereich auf. Die Option -m gibt eine kurze Nachricht an, die die Änderung beschreibt; die Anführungszeichen halten ihre Wörter zusammen:
git commit -m "Deliver ticket message and safe configuration example"
Erwartet wird eine Commit-Zusammenfassung mit den drei geänderten Pfaden. Commit-IDs und Dateistatistiken können variieren. Konzentriere dich deshalb darauf, was aufgenommen wurde.
git status
Erwartet wird ein sauberes Arbeitsverzeichnis. Die ignorierte private Datei existiert weiterhin, obwohl git status sie nicht auflistet.
Ein Commit ist lokal. Es wurde nichts gepusht, hochgeladen oder mit einem entfernten Dienst geteilt. Das reicht aus, um ohne persönliches Konto die Vorbereitung einer sicheren Übergabe zu üben.
Falls Git meldet, dass nichts zu committen ist, vergleiche git status, git ls-files und den vorgemerkten Diff mit den vorherigen Schritten. Löse einen unerwarteten Zustand nicht durch Löschen des Repositorys oder seiner vorhandenen Historie.
Historie und Geschäftsänderung prüfen
In diesem Schritt prüfst du die Commit-Historie und führst das kleine Programm aus, das du erhalten hast.
Die Option --history des Starters wählt die Gitleaks-Prüfung der Git-Historie aus. Der abschließende Punkt . steht für dieses Repository:
course-secrets --history .
Erwartet wird no leaks found. Der saubere Ausgangs-Commit und dein neuer Auslieferungs-Commit sollten beide die feste Regel erfüllen. Eine zuvor erfolgreiche Dateiprüfung allein würde dieses Historienergebnis nicht nachweisen.
python3 führt das bereitgestellte Python-Programm aus. Du musst in diesem Lab keinen Python-Code bearbeiten oder dessen Syntax verstehen:
python3 service/app.py
Erwartet wird:
DeskLite tickets ready
Bestätige, dass die lokale private Datei außerhalb der Git-Versionsverfolgung bleibt:
ls private.env
git ls-files
Du hast jetzt nützliche Auslieferungsdateien, ein sicheres Konfigurationsbeispiel und einen lokalen Commit ohne die Übungszugangsdaten. Die private Datei wurde nicht gelöscht, und die Geschäftsänderung funktioniert weiterhin. Ein kopierter Prüfbericht oder eine Untersuchungsdatei ist nicht erforderlich.
Zusammenfassung
Du hast lokale private Einstellungen von der Quellcode-Auslieferung getrennt, den Staging-Bereich vor dem Commit geprüft und sowohl die aktuellen Auslieferungsdateien als auch die lokale Git-Historie mit einer festen Zugangsdatenprüfung und maskierter Ausgabe untersucht. Die Geschäftsänderung und das nützliche öffentliche Beispiel bleiben erhalten, während die privaten Einstellungen außerhalb des Commits bleiben.
