Hinweis perev. : Vor einigen Tagen erschien im Blog ein kleiner, aber sehr nützlicher Hinweis für Ingenieure unseres bevorzugten GitLab-Projekts mit Anweisungen, die bei verschiedenen Problemen, die bei der Arbeit mit Git auftreten, Zeit und Nerven sparen. Es ist unwahrscheinlich, dass sie für erfahrene Benutzer neu sind, aber es wird sicherlich diejenigen geben, für die sie nützlich sein werden. Und am Ende dieses Materials haben wir einen kleinen Bonus von uns hinzugefügt. Einen schönen Freitag noch!Wir alle machen Fehler, besonders wenn wir mit komplexen Systemen wie Git arbeiten. Aber denk dran: Git passiert!
Wenn Sie gerade erst mit Git anfangen, lernen Sie die
Grundlagen der Arbeit mit Git in der Befehlszeile. Und hier werde ich darüber sprechen, wie Sie die sechs häufigsten Fehler in Git beheben können.
1. Ups ... Ich habe mich in der Nachricht zum letzten Commit geirrt
Nach mehreren Stunden Codierung ist es leicht, einen Fehler in der Festschreibungsnachricht zu machen. Glücklicherweise ist dies leicht zu beheben:
git commit --amend
Mit diesem Befehl wird ein Texteditor geöffnet, in dem Sie Änderungen an der Nachricht bis zum letzten Commit vornehmen können. Und niemand wird wissen, dass Sie "addded" mit drei "ds" geschrieben haben.
2. Ups ... Ich habe vergessen, die Datei zum letzten Commit hinzuzufügen
Ein weiterer beliebter Fehler in Git ist ein zu voreiliges Commit. Haben Sie vergessen, die Datei hinzuzufügen, sie zu speichern, oder sollten Sie eine kleine Änderung vornehmen, um das Commit sinnvoll zu gestalten? Dein Freund wird wieder
--amend wieder
--amend machen.
Fügen Sie die fehlende Datei hinzu und führen Sie den richtigen Befehl aus:
git add missed-file.txt git commit --amend
Jetzt können Sie die Nachricht entweder korrigieren oder einfach in ihrer ursprünglichen Form speichern (mit der hinzugefügten Datei).
3. Ups ... Ich habe eine Datei hinzugefügt, die sich nicht in diesem Repository befinden sollte
Aber was ist, wenn Sie die gegenteilige Situation haben? Was ist, wenn Sie eine Datei hinzugefügt haben, die Sie nicht festschreiben möchten? Eine irreführende ENV-Datei, ein Build-Verzeichnis oder ein Foto mit einer Katze, die versehentlich im falschen Verzeichnis gespeichert wurde ... Alles ist gelöst.
Wenn Sie nur die
Phase für die Datei ausgeführt haben und diese noch nicht festgeschrieben haben, erfolgt alles durch einfaches
Zurücksetzen der gewünschten Datei (in der Phase):
git reset /assets/img/misty-and-pepper.jpg
Wenn Sie die Änderung dennoch festschreiben, ist ein zusätzlicher vorbereitender Schritt erforderlich:
git reset --soft HEAD~1 git reset /assets/img/misty-and-pepper.jpg rm /assets/img/misty-and-pepper.jpg git commit
Das Commit wird zurückgesetzt, das Bild wird gelöscht und anschließend wird ein neues Commit durchgeführt.
Hinweis perev. : Wie in den Kommentaren zum Originalartikel erwähnt, kann dieses Problem auch mit der bereits erwähnten --amend gelöst werden. Anscheinend wollte der Autor mit diesem Absatz zeigen, wie es sonst noch Möglichkeiten gibt, den Verlauf von Commits zu ändern, um den Fehler zu beheben.4. Ups ... Ich habe Änderungen am Master vorgenommen
Sie arbeiten also an einer neuen Funktion und beeilen sich, ohne einen neuen Zweig dafür zu erstellen. Sie haben bereits eine Reihe von Dateien festgeschrieben, und alle diese Festschreibungen befinden sich im Master. Glücklicherweise kann GitLab Push'y direkt im Master verhindern. Daher können wir alle erforderlichen Änderungen an einem neuen Zweig mit den folgenden drei Befehlen rückgängig machen:
Hinweis : Stellen Sie sicher, dass Sie zuerst Ihre Änderungen mit Nullen versehen oder verstauen - sonst gehen alle verloren! git branch future-brunch git reset HEAD~ --hard git checkout future-brunch
Im Master wird ein neuer Zweig erstellt. Es wird ein Rollback in dem Zustand durchgeführt, in dem er sich vor Ihren Änderungen befand, und anschließend wird
der neue Zweig mit all Ihren Änderungen ausgecheckt.
5. Ups ... Ich habe einen Fehler im Namen der Filiale gemacht
Die aufmerksamsten konnten im vorherigen Beispiel einen Fehler im Namen der Niederlassung feststellen. Es ist fast 15 Uhr, und ich habe immer noch nicht zu Abend gegessen, also nannte mein Hunger den neuen Zweig (
br a nch ) als
Zukunftsbrun nch . Goodies!
Benennen Sie diesen Zweig auf die gleiche Weise um, die beim Umbenennen einer Datei mit dem Befehl
mv verwendet wird,
dh platzieren Sie sie an einem neuen Speicherort mit dem richtigen Namen:
git branch -m future-brunch feature-branch
Wenn Sie diesen Zweig bereits pushen, benötigen Sie einige zusätzliche Schritte. Wir werden den alten Zweig von der
Fernbedienung entfernen und den neuen verschieben:
git push origin --delete future-brunch git push origin feature-branch
Hinweis perev. : Sie können einen Zweig weiterhin von Remote entfernen, indem Sie: git push origin :future-brunch
6. Ups ... ich habe es wieder getan!
Der letzte Befehl für den Fall, dass alles schief gelaufen ist. Als Sie mit Stack Overflow eine Reihe von Lösungen gesammelt und gepusht haben, wurde alles im Repository noch schlimmer als zu Beginn. Wir alle standen uns einmal ähnlich gegenüber ...
git reflog zeigt eine Liste aller von Ihnen ausgeführten Vorgänge. Dann können Sie die magischen Zeitreisefunktionen von Git nutzen, d. H. kehre zu jedem Moment aus der Vergangenheit zurück. Ich muss beachten, dass dies Ihre letzte Hoffnung ist - Sie sollten in einfachen Fällen nicht darauf zurückgreifen. Um die Liste zu erhalten, gehen Sie wie folgt vor:
git reflog
Jeder unserer Schritte steht unter dem wachsamen Auge von Git. Das Team für das oben genannte Projekt zu führen, ergab Folgendes:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch 3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch 2b7e508 (master) HEAD@{3}: reset: moving to HEAD~ 3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo 2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1 37a632d HEAD@{6}: commit: Adds the client logo to the project 2b7e508 (master) HEAD@{7}: reset: moving to HEAD 2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site dfa27a2 HEAD@{9}: reset: moving to HEAD dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site 700d0b5 HEAD@{11}: commit: Addded contributing info to the site efba795 HEAD@{12}: commit (initial): Initial commit
Achten Sie auf die Spalte ganz links - dies ist der Index. Wenn Sie zu einem beliebigen Punkt im Verlauf zurückkehren möchten, führen Sie den folgenden Befehl aus und ersetzen Sie
{index} durch den entsprechenden Wert (z. B.
dfa27a2 ):
git reset HEAD@{index}
Jetzt haben Sie sechs Möglichkeiten, um aus den häufigsten Gitfalls herauszukommen
(Wortspiel: Fallstricke bedeutet „Falle, Fehler“ - ca. übersetzt ) .
Bonus vom Übersetzer
Erstens ein wertvoller Kommentar zu allem, was oben geschrieben wurde (mit Ausnahme von Absatz 5). Beachten Sie, dass diese Aktionen den Verlauf von Commits ändern. Sie sollten daher nur ausgeführt werden, wenn die Änderungen nicht an
remote (push'nut) gesendet wurden. Andernfalls befindet sich das alte fehlerhafte Commit bereits in der
Remote- Verzweigung, und Sie müssen entweder
git pull ausführen (was beim
Zusammenführen der git push --force ist, und der Versuch, den Verlauf zu „löschen“, führt zu schlimmeren Konsequenzen), oder
git push --force , das bei der Arbeit mit Datenverlust behaftet ist ein Zweig von mehreren Personen ...
Jetzt - kleine nützliche Ergänzungen aus unserer Erfahrung:
- Wenn Sie (versehentlich oder nicht) den Zweig geändert haben und zum vorherigen zurückkehren müssen, ist der schnellste Weg die Verwendung von
git checkout - . - Wenn Sie dem Commit versehentlich eine Datei hinzugefügt haben, die dort nicht hinzugefügt werden sollte, aber noch nicht festgeschrieben wurde, verwenden Sie
git reset HEAD path/to/file . Eine ähnliche Situation ist in Absatz 3 beschrieben, aber in Wirklichkeit ist sie weiter gefasst, weil bezieht sich auf unnötige Änderungen im Commit (nicht nur bei einer zusätzlichen Datei). - Es wird empfohlen, nicht zu viel
-p , indem Sie beim Hinzufügen einer Datei zu einem -p Option -p ( git add -p ). Auf diese Weise können Sie jede Änderung überprüfen, die in das Commit eingeht. Beachten Sie jedoch, dass dem Commit keine nicht verfolgten Dateien hinzugefügt werden. Sie müssen ohne diesen Parameter hinzugefügt werden. - Eine Reihe guter Empfehlungen (einschließlich komplexerer) finden Sie im Artikel „ Git-Tutorial: 10 häufig auftretende Git-Probleme und deren Behebung “ von 2014. Beachten Sie insbesondere die Verwendung von
git rebase -i und git rebase -i .
PS vom Übersetzer
Lesen Sie auch in unserem Blog: