Git ist ein leistungsfähiges Werkzeug für die Versionskontrolle und hat in diesem Bereich eine Art Monopolstellung. Für die meisten alltäglichen Aufgaben ist Git dank seiner Befehlswiederholungen einfach zu verwenden. Es gibt jedoch viele Situationen, in denen du mehr als nur die Grundlagen brauchst. Deshalb gibt es viele fortgeschrittene Git-Befehle, mit denen du deine Git-Kenntnisse auf die nächste Stufe heben kannst.
Dabei lernst du auch verschiedene Git-Konzepte kennen, mit denen du normalerweise nicht konfrontiert wirst. Zum Beispiel das Stashing im Gegensatz zum Commit von Änderungen, das Rebasing und das Hinzufügen von Dateien zu deinem Staging-Bereich. Wenn du sie einmal gelernt hast, wirst du vielleicht feststellen, dass du für dein Team von noch größerem Wert bist.
In diesem Blogbeitrag werden verschiedene Power-Befehle vorgestellt, die du kennen solltest. Um sie zu nutzen, musst du jedoch einige Fähigkeiten, Konzepte und Informationen zur Hand haben. Schauen wir uns das zuerst an.
Empfohlene Voraussetzungen
Auch wenn du die Grundlagen von Git beherrschst und einige der Zwischenbefehle wie git delete verstehst, brauchst du mehr in deinem Werkzeugkasten, um mit fortgeschrittenen Befehlen umgehen zu können.
Die Tipps, die wir hier geben, eignen sich nicht für Git-Anfänger. Wenn Versionskontrolle im Allgemeinen neu für dich ist, empfehlen wir dir, einige Zeit damit zu verbringen, die grundlegenden Befehle täglich zu benutzen, bevor du dein Repertoire erweiterst.
Hier ist eine kurze Liste von Aspekten, die du verstehen musst:
- Grundlegende Git-Konzepte wie Commits, Branches, Pull Requests und mehr.
- Vertrautheit mit den grundlegenden Git-Befehlen wie
git add,git merge,git commitundgit push. - Für fortgeschrittene Git-Aufgaben musst du in der Lage sein, in einem Terminal zu navigieren.
Es ist hilfreich, Erfahrung mit Git in einer Teamumgebung zu haben, da viele dieser Befehle einen großen Einfluss auf eine gemeinsame Codebasis haben können. Es könnte zum Beispiel sein, dass du einige dieser Befehle nur in einer verantwortlichen Position verwendest. Das bedeutet, dass du vorsichtig sein musst und wissen musst, wann du diese Befehle verwendest.
Git für Fortgeschrittene: 12 wichtige Befehle, die du kennen solltest
Der Rest dieses Artikels befasst sich mit 12 verschiedenen fortgeschrittenen Git-Befehlen, die über die Grundlagen hinausgehen und dich in einen Git-Assistenten verwandeln werden. Beginnen wir mit einem Befehl, den du vielleicht häufiger verwendest als andere.
1. Rebasing
Rebasing ist ein mächtiger Git-Befehl, der eine Alternative zu einer Pull-Anfrage ist. Mit ihm kannst du alle neuen Commits, die du nach einer Zweig-Divergenz machst, in einen neuen Branch ziehen und die Änderungen an der Spitze der Basis einfügen. Das ist nützlich, wenn du aus irgendeinem Grund Änderungen aus einem anderen Zweig übernehmen willst, ohne einen Merge Commit zu erstellen.
Ein häufiger Anwendungsfall für das Rebasing ist, wenn du an einem Feature-Zweig arbeitest und Änderungen aus dem Hauptzweig übernehmen willst, ohne einen Merge Commit zu erstellen. Das hilft dabei, die Historie deines Projekts sauber zu halten, obwohl es länger dauern kann und du beim Zusammenführen mehr Fehler siehst.
Um einen Zweig neu zu verankern, verwendest du den Befehl git rebase. Hier ein Beispiel, bei dem wir einen Zweig auf einen anderen umbinden:
git checkout foo-branch
git rebase main
Du kannst auch die Commits auflisten, die du veröffentlichen willst, und sie vorher bearbeiten. So kannst du Commits zusammenfassen, Commit-Nachrichten bearbeiten und vieles mehr. Du kannst das --interactive oder --i Flag verwenden, um einen „interaktiven Rebase“ durchzuführen
git rebase --interactive <other-branch-name>Apropos, das Zusammenfassen von Commits zu einem einzigen, um die Commit-Historie aufzuräumen, ist ein häufiger Anwendungsfall für Rebase. Dadurch wird dein Commit-Verlauf leichter zu lesen und zu verstehen.
Bei einem Rebase folgst du dem Flag mit der Anzahl der Commits, die du zusammenführen möchtest, um die Commits zu einem einzigen zu kombinieren:
git rebase -i HEAD~3
Daraufhin öffnet sich ein interaktives Rebase-Fenster, ähnlich wie ein Commit-Fenster, in dem du die Commits, die du entfernen möchtest, auswählen und bearbeiten kannst:
Oben auf dem Bildschirm siehst du eine Liste der Commits und unten eine Auswahl an Befehlen sowie einige andere wichtige Informationen. Die Standardoption ist pick, mit der du einen Commit als denjenigen auswählst, den du ohne Änderungen verwenden willst.
Es gibt aber noch viele andere Befehle, die dir beim Rebase helfen. Du kannst zum Beispiel einen Commit neu formulieren oder mehrere Commits zusammenfassen. Um Änderungen vorzunehmen und die Befehle zu verwenden, wirst du mit dem Editor deines Terminals arbeiten. Die Standardeinstellung ist oft Vim, was bedeutet, dass du diesen Editor kennen musst.
Der letzte Schritt besteht darin, deine Änderungen zu speichern und sie dann in den remoten Zweig zu übertragen.
2. Rückgängig machen, Zurücksetzen und Unstaging
Git ist berüchtigt, wenn es darum geht, Änderungen rückgängig zu machen. Es ist generell ein schwieriger Prozess, der oft zu Fehlern führt. Wenn du jedoch Änderungen in deinem Arbeitsverzeichnis oder Staging-Bereich vorgenommen hast, die du rückgängig machen möchtest, gibt es einige Git-Befehle, die dir dabei helfen können.
Git gibt dir sogar eine Anleitung, wie du eine Datei rückgängig machen kannst, wenn du ein git status ausführst:
So kannst du eine Übergabe aus dem aktuellen Zweig entfernen und sie problemlos an einen anderen Zweig senden:
git reset HEAD <commit>
Das hat den Effekt, dass du deinen Zweig um einen Commit zurücksetzt, so als ob du den letzten bekannten Commit entfernst. Es kann sogar vorkommen, dass du einen Zweig auf seinen ursprünglichen Zustand zurücksetzen möchtest. In diesem Fall kannst du ihn gegen den Remote-Ursprung zurücksetzen – zum Beispiel mit git reset --hard origin/main. Beachte jedoch, dass diese Änderungen dann für immer verschwunden sind.
Den Befehl git checkout wirst du zwar häufig verwenden und er gilt als grundlegend, du kannst ihn aber auch verwenden, um Dateien vor einem Commit freizugeben:
git checkout -- <filename>
Beachte das Leerzeichen zwischen den Bindestrichen und dem Platzhalter für den Dateinamen. In diesem Fall hebt der Befehl den Zustand der angegebenen Datei auf und verwirft die Änderungen aus dem Arbeitsverzeichnis. Beachte, dass dadurch alle lokalen Änderungen, die du an einer Datei vorgenommen hast, gelöscht werden. Vergewissere dich also doppelt und dreifach, dass du die ungespeicherten Änderungen nicht brauchst.
Du kannst auch git revert verwenden, um Änderungen an einer Übertragung vorzunehmen. Dabei werden die Änderungen jedoch nicht rückgängig gemacht, sondern es wird eine neue Übertragung erstellt, indem die Änderungen der vorherigen Übertragung rückgängig gemacht werden.
Der Hauptunterschied besteht darin, dass der Befehl keine Referenzzeiger auf den neuen Commit verschiebt, sondern alte Commits beibehält. Das ist nützlich, wenn du Änderungen rückgängig machen willst, ohne sie aus deinem Commit-Verlauf zu löschen.
Der Befehl erwartet eine Referenz, und es ist ganz einfach, den letzten Commit rückgängig zu machen:
git revert HEAD
Du hast jedoch viel mehr Möglichkeiten, Dateien und Commits wiederherzustellen und zu ändern. Die nächsten beiden Einträge auf dieser Liste der fortgeschrittenen Git-Befehle befassen sich damit.
3. Dateien im Standardzustand wiederherstellen
Mit Git kannst du eine Datei ganz einfach in ihren Standardzustand zurückversetzen, indem du einen relativ neuen Befehl verwendest: git restore. In den meisten Fällen solltest du diesen Befehl als Ersatz für git reset betrachten, da er viel mehr Möglichkeiten bietet. Mit git restore --staged <filename> kannst du zum Beispiel das gleiche Ergebnis erzielen wie mit git reset HEAD.
Der Befehl kann aber noch mehr – du kannst auch Dateien in den Standardzustand zurückversetzen. Wie das geht, siehst du, wenn du auch git status ausführst:
git restore <filename>
Damit werden die Änderungen aus dem Arbeitsverzeichnis entfernt, als ob nichts passiert wäre. Wie bei git checkout -- <filename> solltest du sicherstellen, dass du keine der lokalen Änderungen möchtest, da sie für immer verloren sind.
4. Ändern von Commits
Es wird wahrscheinlich oft vorkommen, dass du einen Commit machst und dann merkst, dass du etwas Wichtiges vergessen hast. Mit Git kannst du den Commit ganz einfach ändern und die fehlenden Änderungen einfügen.
Dafür gibt es einen bestimmten Prozess:
- Zuerst nimmst du die Änderungen in den Dateien vor, die du für das Projekt brauchst.
- Stelle sie wie üblich mit
git addbereit. - Übertrage die Änderungen im Staging-Bereich mit einem anderen Befehl, um den Commit durchzuführen:
git commit --amend
Dadurch wird der ursprüngliche Commit durch den neuen Commit ersetzt, wobei dein Staging-Bereich verwendet wird. Achte also darauf, dass du die alte Version des Commits nicht mehr brauchst, da sie verloren geht. Wir empfehlen dir außerdem, das --amend Flag für lokale Commits zu verwenden und nicht für Remote-Commits, und zwar aus ähnlichen Gründen, wie wir sie an anderer Stelle in diesem Beitrag beschreiben.
Du kannst auch git commit --amend verwenden, um die Commit-Nachricht nur mit dem folgenden Befehl zu bearbeiten:
git commit --amend -m "New commit message"
5. Git Logging
Das Log von Git ist nützlich, um den Verlauf eines Repositorys zu verstehen. Allerdings würden wir den Befehl git log nicht als fortgeschritten bezeichnen. Stattdessen kannst du verschiedene Optionen verwenden, um die Ausgabe nach deinen Bedürfnissen zu filtern:
git log
git log --decorate
git log --stat
Wenn du zum Beispiel einen Protokolleintrag dekorierst, werden die Ref-Namen für alle angezeigten Commits ausgegeben. Die Option --stat zeigt Einfügungen und Löschungen für einen Commit an:
Du kannst auch andere Optionen verwenden, um die Ausgabe des Logs anzupassen – das sogenannte „Commit-Limiting“ Nimm zum Beispiel die folgenden Befehle:
git log --author=<author-name>
git log --grep=<pattern-string>
Hier kannst du das Protokoll nach bestimmten Autorennamen oder Textmustern filtern. Du kannst sogar mehrere Optionen und Flags kombinieren, um ein Protokoll für einen bestimmten Zweck zu erstellen. Nimm zum Beispiel diesen Befehl:
git log --oneline --author=<author-name> --since=<date> feature-temp
Dieser Befehl sucht nach allen Commits mit dem feature-temp Zweig von einem bestimmten Autor seit einem bestimmten Datum und gibt sie dann in einzelnen Zeilen aus. Beachte, dass der Parameter <date> auch eine Zeichenkette sein kann:
--since=”Two weeks ago”
Wenn du eine bestimmte Datei anstelle eines Zweigs suchen willst, kannst du das auch tun:
git log --oneline --author=bartonfink --since=”5 days ago” -- readme.rm
Diese Beispiele zeigen nur ansatzweise, was du mit deinen Logs machen kannst, aber es gibt viele Möglichkeiten, anhand deiner Suchkriterien genaue Commits darin zu finden.
6. Git-Hooks
Wahrscheinlich verwendest du manchmal Makros und andere automatisierte Skripte, um den Code auszuführen. Git bietet diese Funktionen auch in Form von Hooks an. Diese Skripte werden als Reaktion auf bestimmte Ereignisse, wie z. B. Commits oder Pushes, automatisch ausgeführt. Es gibt auch viele Möglichkeiten, Hooks zu verwenden, um die Formatierung von Code zu erzwingen, Tests durchzuführen und vieles mehr.
Es gibt zwei Arten von Hooks: client-seitig und server-seitig:
- Client-seitige Hooks werden durch lokale Aktionen wie Commits und Merges ausgelöst.
- Serverseitige Hooks werden aufgrund von Netzwerkoperationen ausgelöst. Das kann z. B. der Fall sein, wenn ein Projektarchiv einen Push-Commit erhält.
Git füllt dein Projektarchiv immer mit mehreren Beispiel-Hooks, wenn du git init aufrufst. Du musst jedoch die Erweiterung .sample entfernen, um sie nutzen zu können:
Beachte, dass du immer nur eine Art von Hook ausführen kannst, obwohl es mit etwas Arbeit möglich ist, mehrere Skripte auf einmal zu verwenden. Daher sollten deine Dateinamen dem Typ des Hooks entsprechen, den du anhand der Beispielskripte verwenden möchtest: pre-commit, update usw.
Einen Git-Hook erstellen
Um einen Git-Hook zu erstellen, musst du ein ausführbares Skript im Unterverzeichnis .git/hooks ohne Erweiterung erstellen. Es wird trotzdem ausgeführt, solange du es dem Ordner hooks hinzufügst.
Du kannst jede beliebige Skriptsprache verwenden, solange sie als ausführbare Datei ausgeführt werden kann. Wir schlagen Ruby oder Python vor, aber du kannst auch Bash, Perl und viele andere verwenden. Du musst nur den Pfad zu deinem Interpreter ändern, statt den Standardpfad zu Bash:
#!/usr/bin/env python
Von hier aus kannst du deinen Code wie gewohnt schreiben. Hier ist zum Beispiel ein prepare-commit Skript in Python, das den Benutzer dazu auffordert, gute Commit-Nachrichten zu schreiben:
#!/usr/bin/env python
import sys, os
path_commit_msg = sys.argv[1]
with open(commit_msg_filepath, 'w') as f:
f.write("# You’ll need to provide a better commit message than that, buddy!")
Auch wenn es nicht immer notwendig ist, empfehlen wir dir, chmod +x .git/hooks/<hook-name> von der Kommandozeile aus zu starten, um sicherzustellen, dass du es ausführen kannst.
Insgesamt können Hooks ein mächtiges Werkzeug sein, um sich wiederholende Aufgaben zu automatisieren und Best Practices in deinem Team durchzusetzen.
7. Commit-Referrals
In Git identifizierst du Commits anhand des SHA-1-Verschlüsselungshashs. Es ist zwar möglich, Commits anhand ihres vollständigen Hashs zu referenzieren, aber das kann mühsam und fehleranfällig sein:
bc7623b7a94ed3d8feaffaf7580df3eca4f5f5ca
Stattdessen bietet Git mehrere Möglichkeiten, Commits mit kürzeren, einprägsameren Namen zu bezeichnen. Du kannst zum Beispiel einen Zweig- oder Tag-Namen verwenden. Nehmen wir zum Beispiel einen Zweig namens „develop“. Hier ist ein Beispiel, in dem wir uns auf den letzten Commit in diesem Zweig beziehen:
git diff develop..HEAD
Dies zeigt die Unterschiede zwischen dem letzten Commit (HEAD) auf dem Zweig „develop“ und dem aktuellen Commit.
Du kannst dich auch auf einen Commit durch seine relative Position in der Commit-Historie beziehen. Du kannst zum Beispiel auf zwei Commits vor dem aktuellen verweisen, indem du die Abkürzung HEAD~2 verwendest:
git diff HEAD~2..HEAD
Git bietet noch weitere Möglichkeiten, auf Commits zu verweisen, z. B. mit dem Symbol „@“ auf den aktuellen Zweig oder mit dem Symbol „^“ auf den Parent eines Commits. Durch die Verwendung dieser Abkürzungen kannst du bei der Arbeit mit Commits Zeit sparen und Fehler vermeiden.
8. Verstecken
Unter normalen Umständen würdest du denken, dass es keine Möglichkeit gibt, Änderungen an Dateien zu speichern, ohne sie zu committen; das „Stashing“ ist eine Möglichkeit, dies vorübergehend zu tun. Es ist nützlich, wenn du den Zweig wechseln oder an einer anderen Aufgabe arbeiten musst, deine Änderungen aber noch nicht festschreiben willst.
Wenn du zum Beispiel mitten im Arbeitsfluss den Zweig wechseln musst, um an etwas zu arbeiten, kannst du die Änderungen im aktuellen Zweig speichern und den anderen auschecken. Von dort aus kannst du an dem anderen Zweig arbeiten und die Änderungen dann committen und pushen. Anschließend kannst du deine Arbeit im ursprünglichen Zweig auschecken und wiederherstellen.
Um Änderungen zwischenzuspeichern, gibt es zwei Möglichkeiten:
git stash
Du speicherst deine Änderungen in einem neuen Stash und stellst dein Arbeitsverzeichnis auf den letzten HEAD-Commit zurück (den Zustand, in dem du es vor den Änderungen hattest). Du kannst die Änderungen mit git stash list auflisten und den Stash mit git stash show überprüfen. Der letztgenannte Befehl kann auch jedes andere Format akzeptieren, das git diff akzeptiert.
Von hier aus kannst du den Zweig wechseln oder an einer anderen Aufgabe arbeiten. Wenn du deine Änderungen abrufen willst, führst du den folgenden Befehl aus:
git stash apply
Dadurch werden die zuletzt gespeicherten Änderungen auf dein Arbeitsverzeichnis angewendet. Beachte jedoch, dass du immer noch auf Konflikte stoßen kannst, wenn du die Datei zu stark änderst. Schließlich ist git stash nur eine vorübergehende Lösung für das Problem, um das es geht.
Du kannst auch mehrere Stashes haben und wie folgt angeben, welcher Stash angewendet werden soll:
git stash apply stash@{n}
Der Platzhalter {n} nimmt eine ganze Zahl auf, und stash@{0} steht für den neuesten Stash. Die offizielle Git-Dokumentation enthält einige weitere Beispiele für git stash.
9. Bisecting
Wir wetten, dass jeder schon einmal auf einen Fehler oder ein Problem gestoßen ist und nicht wusste, wo er anfangen sollte zu suchen. In solchen Situationen kann dir das „Bisecting“ helfen, schnell den Commit zu finden, der das Problem verursacht hat.
Kurz gesagt, sucht der Befehl nach Bugs durch eine Suche in deinen Commits. Sobald er den fehlerhaften Commit gefunden hat, gibt er ihn an dich zurück. Das Besondere an diesem Befehl sind die vielen Unterbefehle, die du verwenden kannst.
Um Bisecting zu verwenden, musst du zuerst den Befehl git bisect start ausführen. Git führt dich dann zum ersten Commit in der Geschichte deines Projekts.
Von hier aus musst du mit den entsprechenden Befehlen angeben, ob diese Übertragung gut oder schlecht ist:
git bisect good
git bisect bad
Git leitet dich dann zum nächsten Commit weiter, um dessen „Qualität“ zu prüfen Beachte, dass du „good“ auch durch „old“ und „bad“ durch „new“ ersetzen kannst, um deinem speziellen Anwendungsfall gerecht zu werden (obwohl du die Begriffe nicht mischen kannst)
Von hier aus kannst du jeden Commit als gut oder schlecht markieren, bis du den Commit findest, der den Fehler verursacht hat. Du musst aber nicht jeden Commit durchforsten – du kannst genaue Bezeichnungen angeben, um deine Suche einzugrenzen und zu verkürzen:
git bisect bad feature-test
In diesem Fall wird ein Zweigname verwendet, aber es könnte auch eine bestimmte Revision mit einer Ganzzahl, einer Hash-Referenz und mehr sein. Sobald du den Fehler gefunden hast, kannst du einen der folgenden Befehle ausführen, um zu deinem aktuellen Code zurückzukehren:
git bisect reset
Wie bei allen fortgeschrittenen Git-Befehlen auf dieser Liste gibt es noch viel mehr zu verstehen, und die Git-Dokumentation ist hier eine wichtige Lektüre.
10. Verzweigungen vergleichen
In unserem Eintrag über Commit-Referrals haben wir über die Verwendung von git diff gesprochen. Jetzt ist es an der Zeit, das Ganze etwas genauer zu betrachten. Du wirst oft mehrere Zweige haben, die unterschiedliche Änderungen enthalten. Mit Git kannst du die Unterschiede zwischen zwei Zweigen mit dem Befehl git diff vergleichen. Du kannst diesen Befehl auf verschiedene Arten verwenden, oft in Verbindung mit anderen Befehlen, um ein Repo zu untersuchen und zu analysieren.
Der grundlegende Befehl git diff gibt dir eine Ausgabe mit einer Übersicht der Änderungen. Sie sieht ähnlich aus wie die Ausgabe einer Commit-Merge-Untersuchung:
Du kannst jedoch genaue Zweige, Hashes und vieles mehr aufschlüsseln. Um zum Beispiel zwei Zweige zu vergleichen, führst du den Befehl git diff branch1..branch2 aus und ersetzt die Platzhalter:
git diff feature-branch pre-prod
Du kannst auch die Unterschiede zwischen deinem aktuellen Zweig und einem anderen Zweig vergleichen:
git diff HEAD..pre-prod
Wenn du hier zwei Punkte verwendest, erhältst du die Differenz zwischen den beiden Spitzen der Zweige. Wenn du hingegen drei Punkte verwendest, wird der Unterschied zwischen dem gemeinsamen Vorfahren der beiden Zweige ermittelt und für den Test verwendet.
Ähnlich wie bei git log kannst du die Ausgabe bereinigen und die Ergebnisse verfeinern. Zum Beispiel prüft git diff --name-only branch1..branch2 nur, welche Dateien sich unterscheiden und lässt den Kontext weg:
Es kann sein, dass die Ausgabe schwer zu analysieren ist, besonders wenn der „diff“ sehr lang ist. In diesen Fällen kannst du die Option --color-words verwenden:
Insgesamt kann git diff genauso leistungsfähig sein wie andere Befehle, vor allem, wenn du bestimmte Optionen aufrufst und die Unterschiede, die du zurückbekommst, verfeinerst.
11. Anwenden einzelner Commits
Manchmal möchtest du einen bestimmten Commit von einem Branch auf einen anderen anwenden, ohne die beiden Branches zusammenzuführen. In Git kannst du dies mit git cherry-pick tun. Du solltest diese Funktion mit Bedacht einsetzen, aber git cherry-pick kann dir in einigen Fällen helfen.
Eine Situation ist, wenn du veraltete Feature-Zweige hast, die du nicht in main oder trunk zusammenführst. Du könntest eine Kombination von Befehlen (wie git log) verwenden, um alte relevante Commits auszugraben und sie an anderer Stelle wieder anzuwenden.
Verwende git log, um die Referenz eines Commits zu finden. Vergewissere dich dann, dass du dich in dem Zweig befindest, auf den du eine Referenz anwenden möchtest. Nehmen wir zum Beispiel an, du möchtest den Commit xxxxxaaaaaa in den Zweig „trunk“ übernehmen. Checke zuerst deinen Zweig aus..
git checkout trunk
…und wähle dann deinen Commit aus:
git cherry-pick xxxxxaaaaaa
Deine Commit-Nachricht wird wahrscheinlich oft nicht mehr aktuell sein. Um dieses Problem zu lösen, kannst du die Option --edit an den Befehl übergeben. Damit kannst du eine neue Commit-Nachricht vor dem Cherry Picking eingeben.
12. ‚Git add‘ boosten
Für unseren letzten fortgeschrittenen Git-Power-Befehl zeigen wir dir git add. Nein, das ist kein Tippfehler – dieser grundlegende Git-Befehl hat einige überraschende Funktionen unter seiner Haube.
Wenn du zum Beispiel einzelne Dateien zum Staging-Bereich hinzufügst, kannst du Folgendes verwenden:
git add -p
Mit der Option -p kannst du Änderungen interaktiv einfügen. Du kannst die Änderungen, die du an jeder Datei vorgenommen hast, überprüfen und dann auswählen, welche du bereitstellen möchtest. So kannst du viel Zeit sparen und vermeiden, dass du eine ungewollte Änderung einstellst.
Du weißt vielleicht, dass du einzelne Dateien bereitstellen kannst, aber du kannst auch ein Verzeichnis angeben. Wenn du zum Beispiel alle Dateien im Verzeichnis „new-feature“ bereitstellen möchtest, kannst du das tun:
git add new-feature
Vielleicht möchtest du sogar sehen, wie das Ergebnis von git add aussieht, ohne den Prozess vollständig auszuführen. Dafür hast du eine Option:
git add --dry-run
git add -n
Wenn du diesen Vorgang ausführst, zeigt dir Git an, ob es die Dateien hinzufügen oder ignorieren wird. Apropos ignorierte Dateien: Du kannst sie auch zum Staging-Bereich hinzufügen, wenn du das möchtest:
git add --force
git add -f
Das Hinzufügen von Dateien zum Staging-Bereich kann komplexer sein als ein einfaches binäres „Hinzufügen oder nicht hinzufügen“-Szenario. So kann einer der wichtigsten Befehle von Git unzählige Eventualitäten abdecken.
Zusammenfassung
Wenn du die grundlegenden Git-Befehle in der Tasche hast, hast du 80 Prozent dessen, was du brauchst, um die regulären Versionskontrollaufgaben deines Projekts zu erledigen. Bei den letzten 20 Prozent können jedoch die fortgeschrittenen Git-Befehle glänzen.
Befehle und Techniken wie Rebasing, Bisecting, Wiederherstellen von Dateien und mehr helfen dir schnell aus der Patsche. Außerdem kannst du deinem Team und deinem Projekt einen größeren Nutzen bieten und dazu beitragen, Arbeitsabläufe zu rationalisieren, die Produktivität zu steigern und eine größere Wirkung als Entwickler zu erzielen.
Wird einer dieser fortgeschrittenen Git-Befehle Teil deiner täglichen Arbeit werden? Lass es uns in den Kommentaren unten wissen!
Schreibe einen Kommentar