Löschen eines lokalen Git-Zweigs. Die häufigsten Git-bezogenen Fehler und Fragen sowie praktische Möglichkeiten, sie zu lösen

Remote-Filialen sind Links zum Status der Zweige in Ihren Remote-Repositorys. Dies sind lokale Zweige, die nicht verschoben werden können. Sie verschieben sich automatisch, wenn Sie über das Netzwerk kommunizieren. Remote-Zweige fungieren als Lesezeichen, um Sie daran zu erinnern, wo sich Zweige in Remote-Repositorys befanden, als Sie das letzte Mal eine Verbindung zu ihnen hergestellt haben.

Sie sehen aus wie (Remote-Repo-Name)/(Branch) . Wenn Sie beispielsweise sehen möchten, wie der Master-Zweig auf dem Ursprungsserver aussah, als Sie das letzte Mal eine Verbindung hergestellt haben, überprüfen Sie den Ursprungs-/Master-Zweig. Wenn Sie und ein Partner an demselben Problem arbeiten und dieser eine iss53-Zweigstelle veröffentlicht hat, haben Sie möglicherweise Ihre eigene lokale iss53-Zweigstelle; aber dieser Zweig auf dem Server zeigt auf einen Commit in origin/iss53 .

Das alles ist vielleicht verwirrend, also schauen wir uns ein Beispiel an. Nehmen wir an, Sie haben einen Git-Server in Ihrem Netzwerk unter git.ourcompany.com. Wenn Sie etwas daraus klonen, nennt Git es automatisch origin , übernimmt alle Daten von dort, erstellt einen Zeiger auf alles, worauf der Master-Zweig dort verweist, und nennt es lokal origin/master (Sie können es jedoch nicht verschieben). Git erstellt Ihnen auch Ihren eigenen Master-Zweig, der am selben Ort wie der Master-Zweig im Ursprung beginnt, sodass Sie etwas haben, mit dem Sie arbeiten können (siehe Abbildung 3-22).

Abbildung 3-22. Durch das Klonen eines Git-Projekts erhalten Sie Ihren eigenen Master-Zweig und origin/master, der auf den Master-Zweig im Ursprung verweist.

Wenn Sie etwas in Ihrem lokalen Master-Zweig tun und in der Zwischenzeit jemand anderes Änderungen an git.ourcompany.com pusht und den Master-Zweig dort aktualisiert, dann werden Ihre Geschichten anders weitergehen. Außerdem wird sich Ihr Ursprungs-/Masterzeiger nicht bewegen, bis Sie den Ursprungsserver kontaktieren (siehe Abbildung 3-23).

Abbildung 3-23. Wenn lokal gearbeitet wird und jemand Änderungen auf einen Remote-Server überträgt, geht jede Geschichte anders weiter.

Um Ihre Arbeit synchron zu halten, führen Sie git fetch origin aus. Dieser Befehl sucht nach dem Serverursprung (in unserem Fall ist es git.ourcompany.com); extrahiert von dort alle Daten, die Sie noch nicht haben, und aktualisiert Ihren lokalen Datenspeicher; Verschiebt den Ursprungs-/Masterzeiger an eine neue Position (siehe Abbildung 3-24).

Abbildung 3-24. Der Befehl „git fetch“ aktualisiert Ihre Remote-Referenzen.

Um zu veranschaulichen, wie Remote-Branches in einer Multi-Remote-Situation aussehen würden, nehmen wir an, Sie haben einen anderen Back-End-Git-Server, der nur von einem Ihrer Entwicklungsteams für die Entwicklung verwendet wird. Dieser Server befindet sich unter git.team1.ourcompany.com. Sie können ihn mit dem Befehl git remote add als neue Remote-Referenz zu dem Projekt hinzufügen, an dem Sie gerade arbeiten, wie in Kapitel 2 beschrieben. Benennen Sie diesen Remote-Server teamone , was die Abkürzung für die vollständige URL ist (siehe Abbildung .3). -25).

Abbildung 3-25. Hinzufügen eines zusätzlichen Remote-Servers.

Jetzt können Sie mit git fetch teamone alles auf dem Server abrufen, was Sie nicht tun. Seit in dieser Moment Dieser Server verfügt nur über einen Bruchteil der Daten, die sich auf dem Ursprungsserver befinden. Git ruft keine Daten ab, sondern pusht einen Remote-Zweig namens teamone/master , der auf denselben Commit verweist wie der Master-Zweig auf dem Teamone-Server (siehe Abbildung). 3 -26).

Abbildung 3-26. Sie haben jetzt einen lokalen Link zur Hauptniederlassung auf Teamone.

Änderungen einreichen

Wenn Sie einen Serverfix-Zweig haben, an dem Sie mit jemand anderem arbeiten möchten, können Sie ihn genauso pushen, wie Sie Ihren ersten Branch gepusht haben. Führen Sie einen Git-Push (Remote-Server) (Zweig) durch:

$ git push origin serverfix Objekte zählen: 20, fertig. Objekte komprimieren: 100 % (14/14), fertig. Schreibobjekte: 100 % (15/15), 1,74 KiB, fertig. Insgesamt 15 (Delta 5), ​​wiederverwendet 0 (Delta 0) Bis [email protected]:schacon/simplegit.git * serverfix -> serverfix

Es ist eine Art Abkürzung. Git erweitert den Namen des Serverfix-Zweigs automatisch zu refs/heads/serverfix:refs/heads/serverfix, was bedeutet: „Nimm meinen lokalen Serverfix-Zweig und aktualisiere den Remote-Serverfix-Zweig von dort aus“. Wir werden den refs/heads/-Teil ausführlich in Kapitel 9 besprechen, er kann jedoch normalerweise weggelassen werden. Sie können auch git push origin serverfix:serverfix verwenden – das Gleiche passiert – es heißt „Nehmen Sie meinen Serverfix und machen Sie ihn zu einem Remote-Serverfix“. Sie können dieses Format verwenden, um einen lokalen Zweig an einen Remote-Zweig mit einem anderen Namen zu übertragen. Wenn Sie nicht möchten, dass der Zweig auf dem Remote-Server serverfix heißt, führen Sie git push origin serverfix:awesomebranch anstelle des vorherigen Befehls aus. Dadurch wird Ihr lokaler Serverfix-Zweig an den awesomebranch-Zweig des Remote-Projekts gesendet.

$ git fetch origin remote: Objekte zählen: 20, fertig. remote: Objekte komprimieren: 100 % (14/14), fertig. remote: Gesamt 15 (Delta 5), ​​wiederverwendet 0 (Delta 0) Objekte auspacken: 100 % (15/15), fertig. Von [email protected]:schacon/simplegit * serverfix -> origin/serverfix

Es ist wichtig zu beachten, dass Sie, wenn Sie beim Abrufen von Daten neue Remote-Branches erhalten, nicht automatisch lokal bearbeitbare Kopien davon erhalten. Mit anderen Worten: In unserem Fall erhalten Sie keinen neuen Serverfix-Zweig, sondern nur einen Origin-/Serverfix-Zeiger, den Sie nicht ändern können.

Um diese Entwicklungen in Ihrem aktuellen Arbeitszweig zusammenzuführen, führen Sie git merge origin/serverfix aus. Wenn Sie Ihren eigenen Serverfix-Zweig zum Arbeiten benötigen, können Sie ihn von einem Remote-Zweig aus erstellen:

$ git checkout -b serverfix origin/serverfix Zweigstellen-Serverfix wurde eingerichtet, um Referenzen/Remotes/Origin/Serverfix der entfernten Zweigstelle zu verfolgen. Auf einen neuen Zweig „serverfix“ umgestellt

Dadurch erhalten Sie eine lokale Niederlassung, an der Sie arbeiten können. Es beginnt dort, wo sich origin/serverfix befindet.

Filialverfolgung

Beim Auschecken eines lokalen Zweigs mit git checkout von einem entfernten Zweig wird automatisch das aufgerufen, was aufgerufen wird verfolgter Zweig. Verfolgte Zweige sind lokale Zweige, die direkt mit einem Remote-Zweig verknüpft sind. Wenn Sie git push eingeben, während Sie sich in einem verfolgten Zweig befinden, weiß Git bereits, auf welchen Server und welchen Zweig Änderungen übertragen werden sollen. Wenn Sie einen Git-Pull auf einen dieser Zweige ausführen, werden in ähnlicher Weise zunächst alle Remote-Referenzen abgerufen und dann automatisch mit dem entsprechenden Remote-Zweig zusammengeführt.

Durch das Klonen eines Repositorys wird in der Regel automatisch ein Master-Zweig erstellt, der origin/master verfolgt, sodass Git Push und Git Pull sofort für diesen Zweig funktionieren und keine zusätzlichen Argumente erfordern. Sie können jedoch auch andere Zweige des Remote-Repositorys verfolgen. Sie haben gerade ein einfaches Beispiel dafür gesehen – git checkout -b [branch] [delete. server]/[branch] . Wenn Sie verwenden Git-Versionen 1.6.2 oder höher können Sie auch die Abkürzung --track verwenden:

$ git checkout --track origin/serverfix Branch-Serverfix wurde eingerichtet, um Remote-Branch-Refs/Remotes/Origin/Serverfix zu verfolgen. Auf einen neuen Zweig „serverfix“ umgestellt

Um einen lokalen Zweig mit einem anderen Namen als den entfernten Zweig einzurichten, können Sie problemlos die erste Version mit einem anderen lokalen Zweignamen verwenden:

$ git checkout -b sf origin/serverfix Branch sf wurde eingerichtet, um Remote Branch refs/remotes/origin/serverfix zu verfolgen. Auf einen neuen Zweig „sf“ umgestellt

Jetzt wird Ihr lokaler SF-Zweig automatisch Änderungen von Origin/Serverfix übertragen und abrufen.

Zweige auf einem Remote-Server löschen

Nehmen wir an, Sie und Ihre Co-Autoren haben eine Innovation fertiggestellt und sie in den Hauptzweig auf einem Remote-Server (oder einen anderen Zweig, in dem der stabile Code gespeichert ist) eingefügt. Sie können einen Zweig auf einem Remote-Server löschen, indem Sie die etwas alberne Syntax git push [remote] verwenden. server] :[branch] . Führen Sie Folgendes aus, um den Serverfix-Zweig auf dem Server zu entfernen:

$ git push origin:serverfix An [email protected]:schacon/simplegit.git-serverfix

Klatschen. Kein Zweig mehr auf Ihrem Server. Möglicherweise möchten Sie die aktuelle Seite mit einem Lesezeichen versehen, da Sie diesen Befehl benötigen und höchstwahrscheinlich die Syntax vergessen werden. Sie können sich diesen Befehl merken, indem Sie zur Syntax git push [remote] zurückkehren. Server] [loc. Zweig]:[löschen branch] , worüber wir etwas früher nachgedacht haben. Teil weglassen [loc. branch] sagen Sie im Wesentlichen: „Nehmen Sie nichts aus meinem Repository und machen Sie [löschen. Zweig] war derselbe“.

Wenn Sie die Teile von Git kennenlernen möchten, nach denen Sie bisher Angst hatten zu fragen, dann ist diese Liste genau das Richtige für Sie. Hier sind die typischsten Situationen und Möglichkeiten zu ihrer Lösung zusammengestellt, sowohl aus der persönlichen Erfahrung des Autors als auch aus dem gesamten Internet.

Fehler im Commit-Kommentar

Wenn der Commit noch nicht an den Server gesendet wurde (Push), können Sie einen einfachen Befehl verwenden, mit dem Sie den Nachrichtentext für den letzten Commit bearbeiten können.

git commit --amend

Wie kann ich das letzte Commit rückgängig machen?

Sie können Git Reset wie folgt verwenden:

Idiot zurücksetzen --hard KOPF~1

HEAD~1 bedeutet ein Commit vor HEAD, d. h. zur aktuellen Position. Es ist erwähnenswert, dass es sich hierbei um eine „nukleare“ Methode handelt, die alle Änderungen rückgängig macht. Wenn Sie alles speichern müssen, was Sie getan, aber noch nicht festgeschrieben haben, verwenden Sie Folgendes:

git reset --soft HEAD~1

Zweig auf dem Server löschen

git push origin --delete branchname

Was ist der Unterschied zwischen „git pull“ und „git fetch“?

Git Pull ist im Wesentlichen Git Fetch, gefolgt von Git Merge. git fetch ruft Änderungen vom Server ab und speichert sie in refs/remotes/ . Lokale Filialen und aktuelle Änderungen sind davon in keiner Weise betroffen. Und Git Pull führt alle diese Änderungen bereits in der lokalen Kopie zusammen.

Wie kann ich „git add“ vor dem Commit rückgängig machen?

Sie haben versehentlich den Dateinamen hinzugefügt und möchten das Hinzufügen dieser Datei rückgängig machen. Wenn der Commit noch nicht erfolgt ist, hilft Folgendes:

Git-Reset-Dateiname

Wie lassen sich Zusammenführungskonflikte lösen?

Verwenden Sie git mergetool , das eine praktische Schnittstelle zum Lösen von Konflikten bietet.

Entfernen Sie alle lokalen Dateien und Verzeichnisse, die nicht von Git verfolgt werden, aus Ihrer aktuellen Kopie

Sorgfältig! Machen Sie lieber vorher ein Backup.

Klonen Sie alle Zweige vom Server

Höchstwahrscheinlich haben Sie dies bereits getan und die Zweige werden einfach ausgeblendet. Hier ist der Befehl, um sie alle anzuzeigen:

Sie können git checkout origin/branchname verwenden, um den richtigen Zweig anzuzeigen. Oder git checkout -b branchname origin/branchname, um einen lokalen Zweig zu erstellen, der dem entfernten Zweig entspricht.

Lokalen Zweig umbenennen

git branch -m alter Name neuer Name

Kehren Sie zu einem beliebigen Commit zurück

Sie können „Reset“ wie zuvor gezeigt verwenden, aber das würde bedeuten, dass Sie dauerhaft zu dem Zustand zurückkehren möchten, in dem Sie sich befanden, und ihn nicht nur ansehen möchten (dazu müssen Sie einen Checkout durchführen). Die Commit-ID muss mit der in der Ausgabe des Git-Log-Befehls angezeigten ID übereinstimmen.

git reset --hard commit_id

Auch hier werden alle aktuellen Änderungen rückgängig gemacht. Stellen Sie also sicher, dass es wirklich das ist, was Sie möchten. Oder verwenden Sie --soft anstelle von --hard .

Ein Submodul (Submodul) löschen

Das Erstellen von Submodulen wird selten verwendet, aber manchmal werden sie trotzdem benötigt. Hier ist also, was Sie brauchen:

git submodule deinit submodulename
git rm Submodulname
git rm --cached Submodulname
rm -rf .git/modules/submodulename

Überschreiben Sie lokale Dateien während des Git-Pulls

Git Reset wird Ihnen wieder helfen:

git fetch --all
git reset --hard origin/master

Wie füge ich einem Repository ein leeres Verzeichnis hinzu?

Auf keinen Fall! Es wird einfach nicht unterstützt und man geht davon aus, dass Sie es nicht benötigen. Aber es gibt einen Trick. Sie können im gewünschten Verzeichnis eine .gitignore-Datei mit folgendem Inhalt erstellen:

# Alles in diesem Verzeichnis ignorieren
*
# Außer der .gitignore-Datei selbst
!.gitignore

Exportieren von Quellen, ähnlich wie „svn export“

Verwenden Sie das Git-Archiv wie folgt:

git archive --format zip --output /path/to/file/file.zip master

Machen Sie alle Änderungen rückgängig, mit Ausnahme derjenigen, die bereits zum geplanten Commit hinzugefügt wurden

git checkout – .

Erstellen Sie auf dem Server einen neuen Zweig aus dem aktuellen lokalen Zweig

git config --global push.default aktuell
git push -u

Gelöschte Datei wiederherstellen

Zuerst müssen Sie den letzten Commit finden, in dem die Datei noch vorhanden war.

Wenn die Passwortauthentifizierung verwendet wird:

1. $ git clone https://Benutzername: [email protected]/opt/git/repository.git

Arbeiten mit Zweigen

1. $ Git-Zweig

1. $ Git-Zweig

1. $ git checkout

1. $ git checkout -b

1. $ git branch -d

1. $ git push origin --delete

Arbeiten mit Commits

Wie entferne ich das letzte Commit?

1. $ git reset --soft HEAD^

Wie ändere ich den letzten Commit?

1. $ git new_file.txt hinzufügen
2. $ git commit --amend

Wie ändere ich den Kommentar zum letzten Commit?

1. $ git commit --amend
2. $ git commit --amend -m "Neuer Kommentar"

Wie füge ich mehrere Commits zusammen?

1. $ git rebase -i HEAD~3

1. pick 1111111 Commit 1 Kommentar
2. pick 2222222 Commit 2 Kommentar
3. pick 3333333 Commit 3 Kommentar

1. pick 1111111 Commit 1 Kommentar
2. Squash 2222222 Commit 2 Kommentar
3. Squash 3333333 Commit 3 Kommentar

Wie kann ich Änderungen an einer bestimmten Datei rückgängig machen und sie in den Zustand zurückversetzen, in dem sie sich nach dem letzten Commit befand?

1. $ git checkout – file.txt

Wie kann ich alle nicht festgeschriebenen (nicht festgeschriebenen) Änderungen rückgängig machen?

1. $ git checkout

Wie kann ich einige Dateien für den nächsten Commit behalten?

1. $ git reset HEAD file.txt

Wenn Sie nicht in ein Remote-Repository pushen können, weil die aktuelle Version des Repositorys niedriger ist als die im Remote-Repository

1. $ git push -f origin master

Zweige zusammenführen

Wie kann ich nur einige Dateien aus einem anderen Zweig übernehmen?

1. $ git checkout branchname -- path/to/file.file

Remote-Repositorys

Informationen zu einem Remote-Repository anzeigen

1. $ git remote show origin

1. * entfernter Ursprung
2. URL abrufen: [email protected]:/opt/git/test-project.git
3. Push-URL: [email protected]:/opt/git/test-project.git
4. HEAD-Zweig: Master
5. Remote-Zweig:
6. Master neu (nächster Abruf wird in Remotes/Origin gespeichert)
7. Lokaler Verweis für „git push“ konfiguriert:
8. Master drückt auf Master (lokal veraltet)

Hinzufügen eines Remote-Repositorys

1. $ git remote Ursprung hinzufügen [email protected]:/opt/git/test-project.git

Remote-Filialen sind Links zum Status der Zweige in Ihren Remote-Repositorys. Dies sind lokale Zweige, die nicht verschoben werden können. Sie verschieben sich automatisch, wenn Sie über das Netzwerk kommunizieren. Remote-Zweige fungieren als Lesezeichen, um Sie daran zu erinnern, wo sich Zweige in Remote-Repositorys befanden, als Sie das letzte Mal eine Verbindung zu ihnen hergestellt haben.

Sie sehen aus wie (Remote-Repo-Name)/(Zweig). Wenn Sie beispielsweise sehen möchten, wie der Master-Zweig auf dem Ursprungsserver aussah, als Sie das letzte Mal eine Verbindung hergestellt haben, überprüfen Sie den Ursprungs-/Master-Zweig. Wenn Sie und ein Partner an demselben Problem arbeiten und dieser eine iss53-Zweigstelle veröffentlicht hat, haben Sie möglicherweise Ihre eigene lokale iss53-Zweigstelle; aber dieser Zweig auf dem Server wird auf einen Commit in origin/iss53 verweisen.

Das alles ist vielleicht verwirrend, also schauen wir uns ein Beispiel an. Ich habe ein Remote-Repository auf GitHub https://github.com/n0tb0dy/RemoreBranches erstellt

Dort habe ich drei Commits gemacht

Beim Klonen eines Remote-Repositorys benennt Git es automatisch Herkunft, übernimmt alle Daten von dort und erstellt einen Zeiger auf das, worauf der Zweig zeigt Meister, und rufen Sie es lokal auf Herkunft/Meister(aber man kann es nicht bewegen). Git macht Sie auch zu Ihrem eigenen Zweig Meister, die an der gleichen Stelle wie die Verzweigung beginnt Meister V Herkunft Sie haben also etwas, mit dem Sie arbeiten können.

„Herkunft“ ist kein besonderer Name

Dies ähnelt dem Namen des Hauptzweigs, der beim Erstellen standardmäßig angegeben wird lokales Repository. Genau wie eine Filiale Meister wird standardmäßig mit dem Befehl erstellt git init, standardmäßig wird derselbe Name verwendet Herkunft auf Befehl Git-Klon. Wenn Sie den Befehl git clone -o booyah ausführen, erhalten Sie booyah/master als Ihren Standard-Remote-Zweig.

Und so kehren wir zu unseren ... Verpflichtungen zurück. Im Remote-Repository sehen sie so aus

Team git fetch empfängt lediglich Updates von einem Server, den Sie noch nicht haben, und ändert Ihr Arbeitsverzeichnis in keiner Weise. Dieser Befehl übernimmt einfach die Daten und ermöglicht Ihnen zu entscheiden, was mit ihnen geschehen soll (mit Ihren Daten kombinieren, bearbeiten usw.).

Team Git-Pull , in den meisten Fällen, führt die empfangenen Daten sofort mit Ihren zusammen.

Normalerweise ist es am besten, einfach die Befehle „git fetch“ und „git merge“ zu verwenden, damit Sie den Zusammenführungsprozess selbst steuern können.

Remote-Zweige löschen

Selbstverständlich bezieht sich dies auch auf das Entfernen von Ästen Remote-Server

$ git push origin --delete serverfix

Klatschen! Und der Zweig auf dem Remote-Server ist weg. Aber im Prinzip löscht dieser Befehl einfach den Verzweigungszeiger auf dem Remote-Server. Der Git-Server speichert weiterhin alle Commit-Informationen, bis Sie den Garbage-Collection-Befehl ausführen.