🏆Abschlussprojekt: Einen vollständigen Projektlebenszyklus aufbauen

Es gibt keine vorbereiteten Dateien und keine alten Commits, denen du folgen könntest. Du stehst in einem initialisierten Repository auf main, und der gesamte Verlauf, den du hinterlässt, wird von dir stammen.

Das ist die Abschlussaufgabe des Kurses. Du führst ein kleines Projekt aus reinen Textdateien durch einen vollständigen Git-Lebenszyklus: Du beginnst es, schützt ausschließlich lokale Pfade, entwickelst auf einem Branch, löst einen Konflikt, stellst verworfene Arbeit wieder her und hinterlässt ein sauberes Repository, das jemand anderes verstehen könnte.

Den leeren Ausgangspunkt prüfen

Führe ein einfaches git status aus, bevor du etwas erstellst. Es sollte main, noch keine Commits und keine Änderungen melden.

git status

Ein Projekt wählen, das klein genug zum Abschließen ist

Wähle etwas, das in ein oder zwei kurzen Textdateien funktioniert: eine Leseliste, eine Packliste, ein Feldtagebuch oder eine andere kleine Idee, die dich interessiert. Wähle Dateinamen und Inhalt selbst. Das Projekt bildet nur den Rahmen; entscheidend sind die Nachweise in seinem Git-Verlauf.

Verwende nano -w mit deinem gewählten Dateinamen, um das Projekt zu erstellen und zu bearbeiten, wie zuvor im Kurs. Speichere jede sinnvolle Änderung, bevor du sie prüfst und in die Staging-Area aufnimmst.

Vom abschließenden main aus müssen mindestens sechs Commits erreichbar sein. Jeder Commit soll eine verständliche Änderung darstellen und eine nützliche Betreffzeile als erste Zeile haben. Eine Betreffzeile ist nützlich, wenn man daran erkennt, was sich geändert hat, ohne den Commit zu öffnen. Eine leere Betreffzeile oder die Einwortplatzhalter wip, update und fix leisten das nicht.

Verwende bei der Arbeit den Prüfablauf aus Kapitel 9: Prüfe mit git status und git diff, nimm mit git add nur die beabsichtigte Änderung in die Staging-Area auf, prüfe die vorbereitete Momentaufnahme mit git diff --staged und committe sie dann. Deine Commit-Anzahl kann über alle folgenden Meilensteine hinweg wachsen. Du brauchst also nicht schon sechs grundlegende Commits, bevor du einen Branch anlegst.

Lokale und erzeugte Pfade schützen

Füge eine reguläre Datei .gitignore hinzu und committe sie. Ihre Regeln sollen virtuelle Umgebungen in .venv/, Python-Cache-Verzeichnisse namens __pycache__/ und Dateien mit der Endung .env aus Git heraushalten.

Verwende git check-ignore mit repräsentativen Pfaden, bevor du dich auf die Regeln verlässt. Die abschließende Verlaufsprüfung untersucht jeden erreichbaren Commit. Einen dieser privaten oder erzeugten Pfade erst zu committen und später zu löschen, reicht deshalb nicht aus. Er darf niemals in den erreichbaren Verlauf gelangen.

Zwei Entwicklungslinien zusammenführen

Erstelle mit git switch -c einen Feature-Branch und mache dort einen sinnvollen Commit. Wähle eine bereits verfolgte Projektdatei, die du auf dem Branch bearbeitest, denn dieselbe Datei wird den Nachweis deiner Konfliktlösung liefern.

Kehre zu main zurück, bearbeite denselben Teil dieser gemeinsamen Datei auf andere Weise und committe dann die Änderung auf dem Hauptbranch. Jetzt enthält keine Seite die andere: Die beiden Branches sind tatsächlich auseinandergegangen.

Führe den Feature-Branch mit git merge in main zusammen. Git sollte wegen eines Konflikts in der gemeinsamen Datei anhalten. Lies die markierten Abschnitte, bearbeite sie zu einem beabsichtigten Ergebnis, das von den Versionen beider Vorgänger-Commits abweicht, nimm die aufgelöste Datei in die Staging-Area auf und schließe den Merge-Commit ab. Nützliche Ideen beider Seiten zu bewahren, ist oft die klarste Lösung. Die genauen Worte bestimmst aber du.

Wenn der Merge als Fast-Forward ohne Konflikt erfolgt, sind die Verläufe nicht auf die erforderliche Weise auseinandergegangen. Lies git log und git branch und ergänze die fehlende unabhängige Arbeit auf dem Hauptbranch und dem Feature-Branch, bevor du diesen Meilenstein erneut versuchst. Der abschließende Nachweis muss einen echten Merge mit zwei Vorgängern enthalten, nicht bloß dieselben Dateien nach einer linearen Folge.

Einen Commit verwerfen und die tatsächliche Arbeit wiederherstellen

Nimm eine weitere echte Projektänderung vor und committe sie. Bestätige den Commit in git log. Verwende dann die destruktive Technik git reset --hard aus Kapitel 4, um main auf einen früheren Commit zurückzusetzen. Das ist hier beabsichtigt: Die Abschlussaufgabe braucht den Nachweis, dass ein echter Commit den Branch verlassen hat.

Lies sofort git reflog. Finde den Eintrag für den Commit, von dem der Reset weggeführt hat, und stelle diese tatsächliche Arbeit mit git cherry-pick wieder her, dem Wiederherstellungsweg aus Kapitel 4. Ähnliche Inhalte in einem neuen Commit erneut einzutippen, ist keine Wiederherstellung, weil dabei die Herkunft aus dem verworfenen Commit verloren geht.

Verwende die Revision, die dein Reflog zeigt. Kopiere keinen Beispielhash aus einer Lektion und rate keine feste Position HEAD@{...}; dein eigener Verlauf bestimmt beides.

Den Verlauf aus Sicht der nächsten mitarbeitenden Person lesen

Lies mit git log die Geschichte vom neuesten zum ältesten Commit. Eine zukünftige mitarbeitende Person sollte die kleinen Anfangsänderungen, das Zusammentreffen der beiden Entwicklungslinien in einem Merge und die tatsächliche Änderung erkennen können, die du wiederhergestellt hast. Vage Betreffzeilen fallen viel leichter auf, wenn du den Verlauf als Geschichte liest, statt ihn als Punktestand zu zählen.

Prüfe .gitignore und verwende git check-ignore noch einmal mit den repräsentativen ausschließlich lokalen Pfaden. Führe dann auf main git status aus und kümmere dich um alles, was zum Projekt gehört und noch in der Staging-Area liegt, geändert, nicht verfolgt oder ungelöst ist. Wenn eine dieser Prüfungen eine Lücke aufdeckt, repariere das Repository mit den bekannten Befehlen, statt ein zweites Projekt neu aufzubauen.

Projektidee, Dateinamen, Name des Feature-Branches, Formulierungen der Nachrichten und Arbeitsweg bestimmst bewusst du. Der gemeinsame Maßstab ist ein lesbarer Verlauf, der beide Entwicklungslinien bewahrt, die Wiederherstellung committeter Arbeit nachweist, rein lokale Dateien heraushält und der nächsten Person einen sauberen Ausgangspunkt hinterlässt.

Füge für diese Abschlussaufgabe kein Remote hinzu und verwende keinen Hostingdienst. Zusammenarbeit wurde in Kapitel 8 geprüft; dieser abschließende Lebenszyklus bleibt innerhalb eines einzelnen lokalen Repositorys ohne Netzwerkzugriff.

Lies zum Abschluss ein letztes Mal git status. Ein sauberer Status ist die Übergabe: Das Projekt hat einen vertrauenswürdigen Verlauf, und die nächste Person kann beginnen, ohne zuerst deine Arbeit entwirren zu müssen.