Wie man nicht verfolgte Dateien in Git entfernt

In Git ist die Datei .gitignore ein unverzichtbares Werkzeug, das Ihnen hilft zu steuern, welche Dateien und Verzeichnisse in Ihr Versionskontroll-Repository aufgenommen werden. Durch die Verwendung von .gitignore können Entwickler verhindern, dass unnötige Dateien wie Logdateien, Abhängigkeiten oder systemspezifische Dateien verfolgt werden. Diese Anleitung zeigt Ihnen, wie Sie eine .gitignore-Datei effizient erstellen und verwenden. Die .gitignore-Datei weist Git an, welche Dateien oder Verzeichnisse in einem Projekt ignoriert werden sollen. Sie ermöglicht es Entwicklern, Dateien auszuschließen, die für das Projekt nicht erforderlich sind, und trägt so zu einer saubereren und effizienteren Versionshistorie bei. Warum .gitignore verwenden? Vermeiden von Unordnung: Verhindern Sie, dass große oder unnötige Dateien Ihr Repository überladen. Datenschutz: Halten Sie sensible Informationen wie API-Schlüssel, Zugangsdaten oder Konfigurationsdateien aus der Versionskontrolle heraus. Effizienz: Optimieren Sie die Zusammenarbeit, indem nur essentielle Dateien verfolgt und geteilt werden. Erstellen einer .gitignore-Datei Das Erstellen einer .gitignore-Datei ist einfach. 1. Navigieren Sie zu Ihrem Git-Repository. Öffnen Sie Ihr Terminal und navigieren Sie in das Stammverzeichnis Ihres Git-Projekts. cd /path/to/your/git/project 2. Erstellen Sie die .gitignore-Datei. Sie können die Datei mit folgendem Befehl erstellen: touch .gitignore 3. Öffnen und bearbeiten Sie die .gitignore-Datei. Öffnen Sie die Datei .gitignore in Ihrem Texteditor und fügen Sie die Dateien oder Verzeichnisse hinzu, die Git ignorieren soll. Zum Beispiel: # node_modules-Ordner ignorierennode_modules/# Logdateien ignorieren*.log# .env-Dateien ignorieren.env 4. Speichern und committen Sie die Änderungen. Nachdem Sie die .gitignore bearbeitet haben, speichern Sie die Datei und committen Sie die Änderungen in Git. git add .gitignoregit commit -m "Add .gitignore" Häufig verwendete Muster in .gitignore Es gibt mehrere gängige Muster, die in .gitignore-Dateien verwendet werden, um Dateien oder Verzeichnisse zum Ausschluss anzugeben. Nachfolgend finden Sie einige Beispiele häufig genutzter Muster. Ignorieren von Dateien anhand ihrer Erweiterung: *.log   # Alle Logdateien ignorieren*.tmp  # Alle temporären Dateien ignorieren*.swp  # Swap-Dateien von Texteditoren ignorieren Ignorieren bestimmter Verzeichnisse: /logs/   # Das logs-Verzeichnis ignorieren/temp/   # Das temp-Verzeichnis ignorieren Ignorieren versteckter Dateien: .*   # Alle versteckten Dateien ignorieren, die mit einem Punkt beginnen (z. B. .DS_Store) Ignorieren von Dateien in einem bestimmten Ordner: /docs/*.pdf   # Alle PDF-Dateien im docs-Ordner ignorieren Negieren eines Musters (Dateien einschließen, die zuvor ausgeschlossen wurden): *.pdf    # Alle PDF-Dateien ignorieren!resume.pdf # resume.pdf nicht ignorieren Dateien global vs. lokal ignorieren Während .gitignore üblicherweise im Stammverzeichnis Ihres Repositories erstellt wird, können Sie Git auch so konfigurieren, dass Dateien global ignoriert werden. Dies gilt dann für alle Repositories auf Ihrem Rechner. Dateien lokal ignorieren Wenn Sie Dateien nur in Ihrem aktuellen Repository ausschließen möchten, bearbeiten Sie einfach die .gitignore-Datei innerhalb dieses Projekts. Dadurch wird sichergestellt, dass der Ausschluss nur für dieses Repository gilt. Dateien global ignorieren Um eine globale .gitignore-Datei zu erstellen, die für all Ihre Repositories gilt, folgen Sie diesen Schritten 1. Erstellen Sie eine globale .gitignore-Datei: touch ~/.gitignore_global 2. Fügen Sie Muster zur globalen .gitignore hinzu: Bearbeiten Sie die Datei und fügen Sie Muster für Dateien hinzu, die Sie global ignorieren möchten. Zum Beispiel: *.log*.tmp.DS_Store 3. Konfigurieren Sie Git zur Verwendung der globalen .gitignore: git config --global core.excludesfile ~/.gitignore_global Best Practices für die Verwendung von .gitignore Um das Beste aus .gitignore herauszuholen, befolgen Sie diese Best Practices: Fügen Sie .gitignore früh hinzu Erstellen Sie eine .gitignore-Datei, sobald Sie ein Projekt starten, um zu verhindern, dass unnötige Dateien verfolgt werden. Halten Sie sie organisiert Organisieren Sie Ihre .gitignore, indem Sie verwandte Muster gruppieren und Kommentare hinzufügen. Zum Beispiel: # Vom Betriebssystem generierte Dateien.DS_StoreThumbs.db# Node.js-Abhängigkeitennode_modules/ Sensible Informationen nicht committen Verwenden Sie .gitignore, um sicherzustellen, dass private Dateien wie API-Schlüssel und Konfigurationseinstellungen nicht versehentlich in die Versionskontrolle gelangen. Testen Sie Ihre .gitignore Verwenden Sie git status, um zu prüfen, ob Ihre .gitignore-Datei Dateien korrekt ausschließt. Wenn eine Datei weiterhin verfolgt wird, wurde sie möglicherweise dem Repository hinzugefügt, bevor sie ignoriert wurde. Fehlerbehebung bei .gitignore-Problemen Manchmal werden Dateien, die ignoriert werden sollten, weiterhin verfolgt. Nachfolgend finden Sie einige häufige Ursachen und Lösungen für .gitignore-Probleme. Bereits verfolgte Dateien Wenn eine Datei dem Repository hinzugefügt wurde, bevor sie in .gitignore aufgenommen wurde, wird sie weiterhin von Git verfolgt. Um das Verfolgen der Datei zu stoppen: 1. Entfernen Sie die Datei aus Git, ohne sie lokal zu löschen: git rm --cached filename 2. Fügen Sie die Datei zur .gitignore hinzu. 3. Committen Sie die aktualisierte .gitignore und das Entfernen der gecachten Datei: git commit -m "Update .gitignore and remove cached files" Probleme mit der Groß- und Kleinschreibung Git unterscheidet zwischen Groß- und Kleinschreibung. Stellen Sie daher sicher, dass die Muster in Ihrer .gitignore-Datei genau der Schreibweise der Dateinamen entsprechen. Zum Beispiel: file.txt # Ignoriert file.txt, aber nicht File.txt Testen mit git check-ignore Um zu prüfen, ob eine Datei korrekt ignoriert wird, können Sie den Befehl git check-ignore verwenden: git check-ignore -v filename Dieser Befehl zeigt die Regel an, die für das Ignorieren einer bestimmten Datei verantwortlich ist. Fazit Durch den effektiven Einsatz von .gitignore können Sie steuern, welche Dateien in Ihr Git-Repository aufgenommen werden und sicherstellen, dass nur essentielle Dateien verfolgt werden. Befolgen Sie die Schritte in dieser Anleitung, um Ihre .gitignore-Datei zu erstellen, anzupassen und Probleme zu beheben, um ein effizientes Versionsmanagement sicherzustellen.

Im Versionskontrollsystem Git gibt es zwei Möglichkeiten, einen Branch mit einem anderen zu kombinieren, die durch unterschiedliche Befehle dargestellt werden: git merge. Commits aus einem Branch werden in einen anderen übertragen, indem ein Merge-Commit erstellt wird. git rebase. Commits aus einem Branch werden in einen anderen übertragen, wobei die ursprüngliche Reihenfolge der Änderungen beibehalten wird. Einfach gesagt: Mit git merge werden die Commits eines Branches zu einem zusammengefasst („squashed“), während sie mit git rebase unverändert bleiben, die Branches aber dennoch kombiniert werden. Der Befehl git rebase ermöglicht also, Commits beider Branches zu einer gemeinsamen Änderungshistorie zusammenzuführen. Dieses Tutorial behandelt den Befehl git rebase, der für das Umsetzen (Rebasing) von Commits (Änderungen) von einem Branch auf einen anderen verantwortlich ist. Alle gezeigten Beispiele verwenden Git Version 2.34.1 auf einem Hostman-Server mit dem Betriebssystem Ubuntu 22.04. Sie können diese Anleitungen verwenden, um Git auf Ihrem Rechner zu installieren: Installing Git on Ubuntu Installing Git on Windows Was ist Git Rebase Git Rebase ist ein leistungsstarker Git-Befehl, der hauptsächlich verwendet wird, um Änderungen von einem Branch in einen anderen zu integrieren, indem die Commit-Historie neu geschrieben wird. Im Gegensatz zu git merge, das einen neuen Merge-Commit erstellt und die Historie beider Branches beibehält, verschiebt oder „wiederholt“ git rebase eine Reihe von Commits von einem Branch auf einen anderen. Das Ergebnis ist eine lineare Historie, die so aussieht, als wäre der Feature-Branch direkt auf dem neuesten Commit des Ziel-Branches (z. B. main oder master) entwickelt worden. Dadurch wird die Commit-Historie aufgeräumt und unnötige Merge-Commits entfernt, was eine klarere und besser nachvollziehbare Projektstruktur schafft. Wie Git Rebase funktioniert Am besten lässt sich verstehen, wie Rebasing in Git funktioniert, wenn man sich ein abstraktes Repository mit mehreren Branches ansieht. Dabei sollte der Rebase-Vorgang Schritt für Schritt betrachtet werden. Erstellen von Branches Angenommen, wir haben ein Repository mit einem einzigen Branch master, der nur einen Commit enthält. Der Branch master sieht folgendermaßen aus: master   commit_1 Dann haben wir auf Basis von master einen neuen Branch hypothesis erstellt, um einige Features zu testen. In diesem neuen Branch haben wir mehrere Commits vorgenommen, die den Code verbessern. Der Branch sieht nun so aus: hypothesis   commit_4   commit_3   commit_2   commit_1 Später haben wir dem Branch master einen weiteren Commit hinzugefügt, um eine Sicherheitslücke dringend zu beheben. Der Branch master sieht jetzt so aus: master   commit_5   commit_1 Unser Repository hat nun zwei Branches: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_1 Der Branch master ist der Hauptbranch, während hypothesis der sekundäre (abgeleitete) Branch ist. Spätere Commits werden über den früheren aufgelistet, ähnlich wie bei der Ausgabe des Befehls git log. Branches zusammenführen Angenommen, wir wollen an dem Feature weiterarbeiten, das wir zuvor in den separaten Branch hypothesis verschoben haben. Dieser Branch enthält jedoch nicht den kritischen Fix, den wir in master vorgenommen haben. Wir möchten daher den Zustand von hypothesis mit master „synchronisieren“, sodass der Fix-Commit auch im Feature-Branch erscheint. Mit anderen Worten, die Struktur des Repositories soll folgendermaßen aussehen: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Wie man sieht, wiederholt hypothesis jetzt genau die Historie von master, obwohl er ursprünglich vor commit_5 erstellt wurde. Hypothesis enthält also die Historie beider Branches – seine eigene und die von master. Um dies zu erreichen, müssen wir git rebase verwenden. Anschließend können die in hypothesis vorgenommenen Änderungen mit dem klassischen Befehl git merge in master zusammengeführt werden, der einen Merge-Commit erstellt. Danach sieht die Repository-Struktur so aus: master   commit_merge   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Außerdem kann das Ausführen von git merge nach git rebase die Wahrscheinlichkeit von Konflikten verringern. Praxis: git rebase Nachdem wir den theoretischen Teil des git rebase-Befehls behandelt haben, können wir ihn nun in einem echten Repository eines Beispielprojekts testen. Die Struktur des Repositories entspricht dem oben beschriebenen theoretischen Beispiel. Erstellen eines Repositories Zuerst erstellen wir ein separates Verzeichnis für das Repository: mkdir rebase Dann wechseln wir hinein: cd rebase Nun initialisieren wir das Repository: git init In der Konsole sollte eine Standard-Informationsmeldung erscheinen: hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: ... Und im aktuellen Verzeichnis erscheint ein versteckter Ordner .git, den Sie mit folgendem Befehl anzeigen können: ls -a Der Parameter -a steht für all und zeigt das Dateisystem im erweiterten Modus an. Sein Inhalt wird sein: .  ..  .git Bevor Commits erstellt werden, müssen wir einige grundlegende Benutzerinformationen angeben. Zuerst den Namen: git config --global user.name "NAME" Dann die E-Mail-Adresse: git config --global user.email "NAME@HOST.COM" Den master-Branch befüllen Mit einfachen Textdateien simulieren wir das Hinzufügen verschiedener Funktionen zum Projekt. Jede neue Funktion wird als separater Commit dargestellt. Erstellen Sie eine Datei für die erste Funktion: nano function_1 Füllen Sie sie mit folgendem Inhalt: Function 1 Indexieren Sie nun die Änderungen: git add . Prüfen Sie zur Sicherheit den Indexierungsstatus: git status In der Konsole sollte folgende Meldung erscheinen, die die indexierten Änderungen anzeigt: On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: function_1 Nun können wir committen: git commit -m "commit_1" Die Konsole zeigt eine Bestätigungsmeldung über den erfolgreichen Commit in master an: [master (root-commit) 4eb7cc3] commit_1  1 file changed, 1 insertion(+)  create mode 100644 function_1 Den hypothesis-Branch befüllen Nun erstellen wir einen neuen Branch namens hypothesis: git checkout -b hypothesis Der Parameter -b sorgt dafür, dass sofort in den neuen Branch gewechselt wird. Die Konsole zeigt eine Bestätigungsmeldung an: Switched to a new branch 'hypothesis' Als Nächstes erstellen wir drei Commits nacheinander mit drei Dateien, analog zu master: commit_2 mit Datei function_2 und Inhalt: Function 2 commit_3 mit Datei function_3 und Inhalt: Function 3 commit_4 mit Datei function_4 und Inhalt: Function 4 Wenn wir dann die Commit-Liste prüfen: git log --oneline zeigt die Konsole folgende Reihenfolge: d3efb82 (HEAD -> hypothesis) commit_4 c9f57b7 commit_3 c977f16 commit_2 4eb7cc3 (master) commit_1 Hier wird der Parameter --oneline verwendet, um die Commit-Informationen in komprimierter Einzeilenform anzuzeigen. Einen Commit zum master-Branch hinzufügen Der letzte Schritt besteht darin, dem Hauptbranch master einen weiteren Commit hinzuzufügen. Wechseln Sie zunächst dorthin: git checkout master Die Konsole bestätigt den Wechsel: Switched to branch 'master' Erstellen Sie nun eine weitere Datei: nano function_5 Mit folgendem Inhalt: Function 5 Indexieren Sie die Änderungen: git add . Und erstellen Sie den neuen Commit: git commit -m "commit_5" Wenn Sie die Commit-Liste prüfen: git log --oneline zeigt der master-Branch jetzt zwei Commits: 3df7a00 (HEAD -> master) commit_5 4eb7cc3 commit_1 Branches mit git rebase zusammenführen Um ein Rebase durchzuführen, müssen Sie zuerst in den hypothesis-Branch wechseln: git checkout hypothesis Und dann das Rebase ausführen: git rebase master Nach Abschluss zeigt die Konsole eine Bestätigungsmeldung an: Successfully rebased and updated refs/heads/hypothesis. Nun können Sie die Commit-Liste prüfen: git log --oneline Die Konsole zeigt nun die Commits beider Branches in der ursprünglichen Reihenfolge: 8ecfd58 (HEAD -> hypothesis) commit_4 f715aba commit_3 ee47470 commit_2 3df7a00 (master) commit_5 4eb7cc3 commit_1 Jetzt enthält der hypothesis-Branch die vollständige Historie des gesamten Repositories. Konflikte auflösen Wie bei git merge können auch beim Befehl git rebase Konflikte auftreten, die manuell gelöst werden müssen. Erzeugen wir absichtlich einen Rebase-Konflikt: Erstellen Sie im hypothesis-Branch eine weitere Datei: nano conflict Und fügen Sie folgenden Text hinzu: There must be a conflict here! Indexieren Sie die Änderungen: git add . Erstellen Sie den Commit: git commit -m "conflict_1" Wechseln Sie nun in den master-Branch: git checkout master Erstellen Sie eine ähnliche Datei: nano conflict Mit folgendem Inhalt: There must NOT be a conflict here! Indexieren Sie wieder: git add . Und committen Sie: git commit -m "conflict_2" Bearbeiten Sie dann die erstellte Datei erneut: nano conflict Und ändern Sie den Inhalt zu: There definitely must NOT be a conflict here! Indexieren Sie die Änderungen erneut: git add . Und erstellen Sie einen weiteren Commit: git commit -m "conflict_3" Wechseln Sie zurück in den hypothesis-Branch: git checkout hypothesis Und führen Sie erneut ein Rebase aus: git rebase master Die Konsole zeigt eine Konfliktmeldung an: Auto-merging conflict CONFLICT (add/add): Merge conflict in conflict error: could not apply 6003ed7... conflict_1 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply 6003ed7... conflict_1 Git schlägt vor, die Konfliktdatei zu bearbeiten, die Änderungen mit git add zu indexieren und dann das Rebase mit --continue fortzusetzen. Das tun wir nun: nano conflict Die Datei enthält zwei widersprückliche Versionen, die in spezielle Markierungen eingefasst sind: <<<<<<< HEAD There definitely must NOT be a conflict here! ======= There must be a conflict here! >>>>>>> 6003ed7 (conflict_1) Unsere Aufgabe ist es, die überflüssigen Teile zu entfernen und die Datei mit einem endgültigen Text zu füllen: There must absolutely definitely unanimously NOT be any conflict here! Indexieren Sie die Änderungen: git add . Und fahren Sie mit dem Rebase fort: git rebase --continue Danach zeigt die Konsole einen Texteditor an, der es Ihnen ermöglicht, die ursprüngliche Commit-Nachricht des Konflikt-Commits zu bearbeiten: conflict_1 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # interactive rebase in progress; onto bd7aefc # Last commands done (4 commands done): # pick 8ecfd58 commit_4 # pick 6003ed7 conflict_1 # No commands remaining. # You are currently rebasing branch 'hypothesis' on 'bd7aefc'. # # Changes to be committed: # modified: conflict # Die Konsole zeigt anschließend eine Meldung über den erfolgreichen Abschluss des Rebase-Prozesses an: [detached HEAD 482db49] conflict_1  1 file changed, 1 insertion(+), 1 deletion(-) Successfully rebased and updated refs/heads/hypothesis. Wenn Sie nun die Commit-Liste im hypothesis-Branch prüfen: git log --oneline sehen Sie die ursprüngliche Reihenfolge aller vorgenommenen Änderungen: 482db49 (HEAD -> hypothesis) conflict_1 bd5d036 commit_4 407e245 commit_3 948b41c commit_2 bd7aefc (master) conflict_3 d98648d conflict_2 3df7a00 commit_5 4eb7cc3 commit_1 Beachten Sie, dass die Commits conflict_2 und conflict_3, die im master-Branch erstellt wurden, in der Historie vor dem Commit conflict_1 erscheinen. Das gilt für alle Commits, die im master-Branch vorgenommen wurden. Rebasing eines Remote-Repositories Neben der Arbeit mit lokalen Branches kann Rebase auch beim Herunterladen von Änderungen aus einem Remote-Repository verwendet werden. Dazu fügt man dem Standardbefehl pull die Option --rebase hinzu: git pull --rebase remote branch Dabei gilt: remote ist das Remote-Repository branch ist der Remote-Branch Im Wesentlichen entspricht diese Pull-Konfiguration einem git rebase, mit dem Unterschied, dass die Änderungen (Commits), die auf den aktuellen Branch angewendet werden, aus dem Remote-Repository stammen. Hauptvorteile von Git Rebase Lineare Historie Der Befehl git rebase ermöglicht es, eine lineare Historie des Ziel-Branches zu erstellen, die aus aufeinanderfolgenden Commits besteht. Eine solche Struktur ohne Verzweigungen macht die Historie leichter verständlich und übersichtlicher. Weniger Konflikte  Das vorherige Ausführen von git rebase kann die Wahrscheinlichkeit von Konflikten beim Zusammenführen von Branches mit git merge deutlich verringern. Konflikte lassen sich in aufeinanderfolgenden Commits einfacher lösen als in einem einzigen Merge-Commit. Dies ist besonders hilfreich beim Pushen von Branches in Remote-Repositories. Nachteile von Git Rebase Veränderung der Historie  Im Gegensatz zum Mergen überschreibt Rebase Teile der Zielbranch-Historie und entfernt überflüssige Elemente. Fehleranfälligkeit  Da Rebase die Commit-Historie erheblich umstrukturieren kann, besteht das Risiko irreversibler Fehler im Repository, wodurch Daten dauerhaft verloren gehen können. Wann sollte man Git Rebase verwenden Git rebase ist besonders nützlich, wenn Sie an kleinen oder individuellen Feature-Branches arbeiten, die später in einen gemeinsamen Hauptbranch integriert werden sollen. Es hilft, eine saubere und lineare Historie zu behalten, was insbesondere bei Open-Source-Projekten oder zur besseren Nachvollziehbarkeit von Änderungen wichtig ist. In Teams mit mehreren Mitwirkenden sollte Rebase jedoch vorsichtig eingesetzt werden, um Probleme durch das Umschreiben der öffentlichen Historie zu vermeiden. Eine gute Kommunikation im Team darüber, wann Rebase angebracht ist, ist entscheidend. In vielen Fällen ist git merge sicherer und einfacher, insbesondere für gemeinsam genutzte Branches oder wenn eine nicht-lineare Historie akzeptabel ist. Wichtige Überlegungen Umschreiben der Historie Ein wesentlicher Aspekt von git rebase ist, dass die Commit-Historie neu geschrieben wird. Dabei ändern sich die SHA-1-Hashes der Commits, was in kollaborativen Umgebungen zu Konflikten führen kann, insbesondere wenn ein bereits veröffentlichter Branch erneut rebased wird. Das Rewriting der Historie kann zu Abweichungen zwischen lokalem und Remote-Repository führen. Keine öffentlichen Branches rebased Als Best Practice gilt, öffentliche Branches, die bereits geteilt wurden, nicht zu rebased. Da Rebase die Historie verändert, kann dies zu divergierenden Historien führen und komplizierte Merge-Konflikte verursachen. Rebase eignet sich am besten für lokale Branches oder zur Vorbereitung eines Feature-Branches vor dem finalen Merge. Öffentliche Branches sollten in der Regel gemergt statt gerebased werden. Mögliche Konflikte Während eines Rebase-Vorgangs kann es zu Konflikten kommen, wenn Änderungen in beiden Branches kollidieren. Git hält den Vorgang dann an und fordert Sie auf, die Konflikte manuell zu lösen. Das Vorgehen ähnelt dem bei Merge-Konflikten, ist jedoch oft aufwendiger, da Konflikte für jeden Commit einzeln gelöst werden müssen. Nach der Lösung können Sie mit git rebase --continue fortfahren. Fazit Das Zusammenführen zweier Branches durch Rebasing, umgesetzt mit dem Befehl git rebase, unterscheidet sich grundlegend vom klassischen Merge mit git merge. git merge fasst die Commits eines Branches zu einem einzigen Commit in einem anderen Branch zusammen. git rebase verschiebt die Commits eines Branches ans Ende eines anderen Branches und behält die ursprüngliche Reihenfolge bei. Ein ähnlicher Effekt kann erzielt werden, wenn git pull mit der Option --rebase verwendet wird. Auf der einen Seite sorgt git rebase für eine sauberere und besser nachvollziehbare Commit-Historie im Hauptbranch und verbessert die Wartbarkeit des Repositories. Auf der anderen Seite reduziert git rebase die Detailtiefe der Historie und entfernt bestimmte Einträge, was die Nachverfolgung erschweren kann. Aus diesem Grund ist Rebase ein Werkzeug für erfahrene Benutzer, die das Verhalten von Git genau verstehen. Meist wird git rebase in Kombination mit git merge verwendet, um eine optimale Struktur von Repository und Branches zu erreichen.