Đoạn xem trước bài giảng

Abschlussprojekt: Simulation einer echten Team-Entwicklung

Wende alles Gelernte in einem zusammenhängenden Szenario an: Du bist Entwickler in einem kleinen Team, das ein neues Feature hinzufügen, einen Bug beheben und ein Release veröffentlichen muss. Wir durchlaufen Schritt für Schritt den kompletten Zyklus: Repository-Erstellung, Arbeiten in Branches, Pull Requests, absichtlich erzeugte Konflikte und deren Lösung, Rebase zur Bereinigung der Historie und abschließender Release-Tag. Am Ende hast du ein echtes Repository in der Hand, das du potenziellen Arbeitgebern zeigen kannst.

Vollständiger Git-Workflow Team-Entwicklung Release-Zyklus

Bạn sẽ học gì trong bài giảng này

Du wirst in der Lage sein, einen vollständigen Entwicklungszyklus für ein Feature in Git durchzuführen – von der Erstellung eines Branches bis zum Merge in den Main-Branch.
Du verstehst, wie ein echter Arbeitsablauf im Team aussieht, und bist ab dem ersten Arbeitstag dafür gerüstet.
Du erhältst ein fertiges Repository mit einer sinnvollen Commit-Historie, das du in deinem Portfolio verwenden und bei Vorstellungsgesprächen präsentieren kannst.

Phần đầu bài giảng

Repository für Ihr Portfolio initialisieren

Neuen Projektordner erstellen
Leeres Git-Repository initialisieren
.gitignore für auszuschließende Dateien hinzufügen
Status des Arbeitsverzeichnisses prüfen

Öffnen Sie das Terminal und erstellen Sie einen neuen Projektordner mit dem Befehl 'mkdir portfolio-projekt'. Wechseln Sie in diesen Ordner und führen Sie 'git init' aus – dies erstellt ein verstecktes .git-Verzeichnis, in dem Git die gesamte Versionshistorie speichert. Fügen Sie nun eine .gitignore-Datei mit den Einträgen 'node_modules/' und '.env' hinzu, um Abhängigkeiten und sensible Daten von der Versionskontrolle auszuschließen. Überprüfen Sie den aktuellen Status mit 'git status' – Sie sollten die neue Datei in der Liste der nicht verfolgten Dateien sehen. Dies ist die Grundlage für Ihr professionelles Projekt. Vergewissern Sie sich, dass alle Dateien korrekt erstellt und an den richtigen Stellen sind.

#!/bin/bash
# Projektordner erstellen
mkdir portfolio-projekt

# In Projektordner wechseln
cd portfolio-projekt

# Git-Repository initialisieren
git init

# .gitignore-Datei erstellen
cat > .gitignore << EOL
node_modules/
.env
EOL

# Repository-Status prüfen
git status

Projektstruktur nach Standards organisieren

Standardordner erstellen: src, docs, tests
README mit Projektbeschreibung hinzufügen
Alle Änderungen für den Commit vorbereiten
Status vor dem Festsetzen prüfen

Eine saubere Projektstruktur ist wie ein aufgeräumter Schreibtisch: Alles hat seinen Platz. Erstellen Sie drei Hauptordner: 'src' für den Quellcode, 'docs' für die Dokumentation und 'tests' für die Testfälle. Fügen Sie eine README.md-Datei mit einer kurzen Projektbeschreibung hinzu. Führen Sie nun 'git add .' aus, um alle Dateien in den Staging-Bereich zu übernehmen. Prüfen Sie mit 'git status' erneut – nun sollten alle neuen Dateien im Bereich der für den Commit vorgesehenen Änderungen erscheinen. Dies ist der erste Schritt zu einer professionell organisierten Codebasis. Stellen Sie sicher, dass die Struktur den Industriestandards entspricht.

#!/bin/bash
# Standardordner erstellen
mkdir src docs tests

# README mit Beschreibung erstellen
cat > README.md << EOL
# Portfolio-Projekt

Dieses Projekt demonstriert Git-Kenntnisse.
EOL

# Alle Dateien zum Staging-Bereich hinzufügen
git add .

# Repository-Status prüfen
git status

Der erste sinnvolle Commit

Erstellen Sie den ersten Commit mit einer klaren Nachricht
Verwenden Sie das Präfix 'chore' für Wartungsänderungen
Überprüfen Sie den Commit-Verlauf
Stellen Sie sicher, dass alle Änderungen erfasst wurden

Es ist an der Zeit, den Ausgangszustand des Projekts zu erfassen. Führen Sie 'git commit -m 'chore: Projektstruktur initialisieren' aus. Beachten Sie das Präfix 'chore' - es kennzeichnet Wartungsänderungen. Nach dem Commit führen Sie 'git log' aus - Sie sehen einen Eintrag über Ihren ersten Commit mit Hash, Autor und Nachricht. Dies ist die Grundlage, auf der die gesamte weitere Änderungshistorie aufbaut. Ein guter erster Commit ist wie eine leere Leinwand für einen Künstler. Stellen Sie sicher, dass die Nachricht verständlich und informativ ist.

#!/bin/bash
# Erstellen des ersten Commits
git commit -m 'chore: Projektstruktur initialisieren'

# Commit-Verlauf überprüfen
git log --oneline

Bài giảng đầy đủ dành cho thuê bao

Còn 31 slide nữa trong phiên bản đầy đủ.

Video, toàn bộ slide, ghi chú, bài kiểm tra, gia sư AI và phỏng vấn sẽ mở sau khi đăng nhập và đăng ký thuê bao.

Đăng nhập hoặc đăng ký Đăng ký thuê bao

Nội dung bài giảng

Repository für Ihr Portfolio initialisieren
Projektstruktur nach Standards organisieren
Der erste sinnvolle Commit
Projekt auf GitHub veröffentlichen
Neues Feature beginnen: Branch erstellen
Atomare Commits: Eine verständliche Änderungshistorie schreiben
Vorbereitung auf das Code-Review
Vorbereitung des Pull Requests
Vorbereitung des Abschlussprojekts für das Review
Pull Request auf GitHub erstellen
Umgang mit Code-Review-Kommentaren
Abschluss des Review-Prozesses
Kritischer Fehler in der Produktion: Was tun?
Hotfix-Branch korrekt erstellen
Schnellkorrektur und Überprüfung
Dringendes Zusammenführen und Ausliefern
Aktualisierung des Feature-Branches vor dem Zusammenführen
Konfliktlösung im Code
Rebase abschließen und pushen
Warum Rebase vor dem Merge wichtig ist
Interaktives Rebase in Aktion
Finale: Merge mit sauberer Historie
Fertiges Feature veröffentlichen
Änderungen per Squash and Merge zusammenführen
Aufräumen nach dem Merge
Endergebnis und was man im Vorstellungsgespräch zeigen sollte
Release-Vorbereitung: Code-Überprüfung
Versionstag v1.0.0 erstellen
Release auf GitHub veröffentlichen
Ergebnis prüfen und für die Weiterentwicklung vorbereiten
Projekthistorie analysieren
Bewertung der Commit-Lesbarkeit
Commit-Historie als professionelles Portfolio
Der letzte Schliff: Ihr erstes Release ist fertig!