Hausaufgabe zu Git-Branches, Merge, Rebase und einem Bash-Support-Tool
📋 Thema • ⚙️ Installation • 📖 Verwendung • 🔧 Git-Befehle • ❓ Theorie
Dieses Repository enthält ein kleines Bash-Skript für einfache Aufgaben im IT-Support. Das Skript begrüßt den Benutzer mit seinem Namen und bietet ein Menü mit folgenden Aktionen:
- 💻 Systeminformationen mit
uname -aanzeigen - 💾 Speicherplatz mit
df -hprüfen - 🚪 Programm beenden
Es ist eine praktische Übung zu den folgenden Git-Konzepten:
- 🌿 Branches erstellen und wechseln
- 🔀 Merging von Branches
- 📝 Theoretischer Vergleich von Merge und Rebase
⚠️ Merge-Konflikte verstehen und lösen
- Bash Shell
- Git installiert
- Grundlegende Terminalkenntnis
- Repository klonen:
git clone https://github.com/harry0203vn/git-shell-hausaufgabe.git
cd git-shell-hausaufgabe- Skript ausführbar machen:
chmod +x support_tool.sh./support_tool.sh- Das Skript fragt nach Ihrem Namen 👤
- Es begrüßt Sie persönlich 👋
- Ein Menü mit 3 Optionen wird angezeigt:
- Option 1: Systeminformationen anzeigen
- Option 2: Speicherplatz prüfen
- Option 3: Programm beenden
IT Support Tool
===============
Dieses Skript hilft bei einfachen Support-Aufgaben.
Bitte geben Sie Ihren Namen ein: Max
Hallo Max, willkommen im IT Support Tool.
Bitte wählen Sie eine Aufgabe:
1) Systeminformationen anzeigen
2) Speicherplatz prüfen
3) Programm beenden
Systeminformationen:
<Ausgabe von uname -a>
- ✅ Gültige Auswahlmöglichkeiten:
1,2,3 - ❌ Andere Eingaben führen zu einer Fehlermeldung
- 🔁 Für eine neue Aktion wird das Skript erneut gestartet
| Befehl | Beschreibung |
|---|---|
git clone |
📥 Repository auf den lokalen Rechner kopieren |
git status |
🔍 Aktuellen Zustand des Arbeitsverzeichnisses prüfen |
git add |
➕ Änderungen für einen Commit vormerken |
git commit |
💾 Einen neuen Stand in der Historie speichern |
git push |
🚀 Commits und Branches zu GitHub hochladen |
git pull |
⬇️ Änderungen von GitHub herunterladen |
git branch |
🌿 Branches anzeigen und verwalten |
git checkout |
🔄 Zwischen Branches wechseln oder neue erstellen |
git merge |
🔀 Änderungen eines Branches zusammenführen |
Ein Merge-Konflikt entsteht, wenn Git Änderungen aus verschiedenen Branches nicht automatisch zusammenführen kann. Git hält den Merge an und verlangt, dass ein Mensch entscheidet, welche Versionen behalten oder kombiniert werden sollen.
2. Warum entsteht ein Merge-Konflikt meistens dann, wenn zwei Branches dieselbe Stelle in derselben Datei verändert haben?
Wenn zwei Branches dieselben Zeilen unterschiedlich verändern, kann Git nicht erkennen, welche Änderung korrekt ist. Beide Versionen sind aus Sicht von Git gültig, deshalb ist eine manuelle Entscheidung notwendig.
Die Branches wurden in der vorgegebenen Reihenfolge erstellt und zuerst in master gemergt. Jeder neue Branch basierte auf dem aktuellen Stand von master, sodass keine widersprechenden Änderungen entstanden.
Git fügt spezielle Konfliktmarkierungen in die betroffene Datei ein. Zwischen diesen Markierungen stehen die unterschiedlichen Versionen der beiden Branches:
<<<<<<< HEAD
Version aus aktuellem Branch
=======
Version aus zusammenzuführendem Branch
>>>>>>> branch-name
Zuerst öffnet man die betroffenen Dateien und entscheidet, welche Änderungen bleiben oder kombiniert werden sollen. Danach entfernt man die Konfliktmarkierungen und testet das Ergebnis. Abschließend markiert man die Dateien mit git add als gelöst und erstellt den Merge-Commit.
- 📂 Betroffene Dateien öffnen
- 🤔 Entscheiden: welche Änderungen behalten/kombinieren?
- ✂️ Konfliktmarkierungen entfernen
- ✅ Änderungen testen
- 📝 Als gelöst markieren:
git add <datei> - 💾 Merge-Commit erstellen:
git commit
6. Warum sollte man nach dem Lösen eines Merge-Konflikts das Programm oder Skript noch einmal testen?
Beim manuellen Zusammenführen können versehentlich Zeilen gelöscht, doppelt übernommen oder falsch kombiniert werden. Ein erneuter Test zeigt, ob das Skript weiterhin korrekt funktioniert und die Lösung fachlich sinnvoll ist. ✅
git merge führt die Änderungen eines Branches in den aktuell ausgecheckten Branch ein. Wenn beide Branches eigene neue Commits besitzen und kein Fast-forward möglich ist, erstellt Git normalerweise einen Merge-Commit.
git checkout master
git merge feature-branchgit rebase setzt die Commits eines Branches auf einen neuen Ausgangspunkt. Die betroffenen Commits werden neu geschrieben und erhalten neue Commit-IDs.
git checkout feature-branch
git rebase mastermerge verbindet zwei Entwicklungsverläufe und bewahrt ihre bestehende Historie. rebase schreibt die Commits eines Branches so um, als wären sie direkt auf dem aktuellen Ziel-Branch entstanden.
| Aspekt | Merge | Rebase |
|---|---|---|
| 📊 Historie | Verzweigungen bleiben sichtbar | Lineare Historie |
| 💾 Commits | Merge-Commit wird erstellt | Commits werden umgeschrieben |
| 🔍 Lesbarkeit | Zeigt wann Branch gemergt wurde | Saubere, lineare Abfolge |
| Niedriger | Höher bei geteilten Branches | |
| 👥 Team | Sicherer für Zusammenarbeit | Besser für lokale Commits |
Ein Merge-Commit dokumentiert ausdrücklich, wann und wie zwei Branches zusammengeführt wurden. Die Verzweigung bleibt in der Git-Historie sichtbar.
Durch Rebase werden Commits hintereinander auf eine Linie gesetzt. Die Historie enthält weniger zusätzliche Merge-Commits und lässt sich leichter von oben nach unten lesen.
Rebase verändert bestehende Commits und ihre IDs. Wenn andere Personen bereits darauf weitergearbeitet haben, können doppelte Commits, schwierige Konflikte und ein erzwungener Push entstehen. Deshalb sollte Rebase möglichst nur auf lokalen, noch nicht geteilten Branches verwendet werden.
Ich würde merge verwenden, wenn ein Branch bereits geteilt wurde oder die tatsächliche Entwicklungsgeschichte erhalten bleiben soll. Für die Zusammenarbeit im Team ist das oft die sicherere und nachvollziehbarere Wahl.
✅ merge verwenden bei:
- 👥 Geteilten Branches
- 📚 Entwicklung, wo Historie wichtig ist
- 🤝 Team-Zusammenarbeit
- 🔒 Remote Branches
Rebase kann sinnvoll sein, um einen eigenen, noch nicht geteilten Feature-Branch auf den neuesten Stand von master zu bringen. So kann man lokale Commits vor dem Teilen ordnen und eine lineare Historie erzeugen.
✅ rebase sinnvoll bei:
- 🔐 Lokalen, noch nicht geteilten Branches
- 📋 Vor dem Veröffentlichung
- 🧹 Saubere lineare Historie gewünscht
- 🎯 Feature-Branches auf aktuellen Stand bringen
git-shell-hausaufgabe/
├── support_tool.sh # 🔧 Hauptskript
└── README.md # 📖 Diese Datei
Nach dieser Hausaufgabe verstehen Sie:
- ✅ Wie Git Branches funktionieren
- ✅ Unterschiede zwischen
mergeundrebase - ✅ Wie Merge-Konflikte entstehen und gelöst werden
- ✅ Best Practices für Zusammenarbeit
- ✅ Praktische Bash-Programmierung
- 🌿 Verwenden Sie aussagekräftige Branch-Namen:
feature/feature-name,bugfix/issue-name - 📝 Schreiben Sie aussagekräftige Commit-Messages
- 🔍 Nutzen Sie
git logum die Historie zu verstehen
- 🧠 Verstehen Sie den Konflikt vollständig
- 💬 Kommunizieren Sie mit Ihrem Team
- 🧪 Testen Sie gründlich nach der Lösung
⚠️ Niemals auf öffentlichen/geteilten Branches rebasen!- 🔐 Nur auf lokalen Entwicklungs-Branches verwenden
- 📌 Stellen Sie sicher, dass niemand anderes auf den Commits arbeitet
- Git Dokumentation - Offizielle Git Docs
- GitHub Guides - Einführungen
- Atlassian Git Tutorials - Detaillierte Tutorials
Für dieses Übungsrepository wurde derzeit keine separate Lizenzdatei hinzugefügt.
Erstellt von: harry0203vn
Letztes Update: 2026-08-25
Status: ✅ Aktiv
⭐ Wenn dieses Projekt hilfreich war, geben Sie gerne einen Star!