Die häufigsten Fehler und Fragen im Zusammenhang mit Git und bequeme Möglichkeiten, sie zu lösen

Bei Verwendung der Passwortauthentifizierung:

1. $ git clone https://username:password@gitsrv/opt/git/repository.git

Arbeiten mit Zweigen

1. $git-Zweig

1. $git-Zweig

1. $git-Kaufabwicklung

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 2 Kommentare schreiben
3. Wählen Sie 3333333. Geben Sie 3 Kommentare ein

1. pick 1111111 Commit 1 Kommentar
2. squash 2222222 2 Kommentare schreiben
3. Squash 3333333 3 Kommentare schreiben

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-Kaufabwicklung

Wie halte ich einige Dateien für das nächste Commit bereit?

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. Abruf-URL: git@gitsrv:/opt/git/test-project.git
3. Push-URL: git@gitsrv:/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 add origin git@gitsrv:/opt/git/test-project.git

Gelöschte Zweige – Dies 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 (Name des Remote-Vertreters)/(Zweigstelle). Wenn Sie beispielsweise sehen möchten, wie der Master-Zweig auf dem Ursprungsserver aussah, als Sie das letzte Mal eine Verbindung hergestellt haben, sehen Sie sich den Ursprungs-/Master-Zweig an. Wenn Sie und ein Partner an demselben Problem gearbeitet haben und dieser eine iss53-Zweigstelle gepostet hat, können Sie Ihre eigene lokale iss53-Zweigstelle einrichten; aber dieser Zweig auf dem Server zeigt auf den Commit in origin/iss53.

Das mag alles verwirrend sein, 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 dort 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, sodass Sie etwas haben, mit dem Sie arbeiten können.

„Herkunft“ ist kein besonderer Name

Dies ähnelt dem Master-Branch-Namen, der beim Erstellen standardmäßig angegeben wird lokales Repository. Genau wie eine Filiale Meister Wird standardmäßig auf Befehl erstellt git init, standardmäßig wird derselbe Name verwendet Herkunft auf Befehl Git-Klon. Wenn Sie den Befehl git clone –o booyah eingeben, 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 Es empfängt lediglich Aktualisierungen vom Server, die Sie noch nicht haben, und ändert Ihr Arbeitsverzeichnis in keiner Weise. Dieser Befehl empfängt einfach die Daten und ermöglicht Ihnen zu entscheiden, was mit ihnen geschehen soll (sie mit Ihren Daten zusammenführen, bearbeiten usw.).

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

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

Entfernen von Remote-Zweigen

Dies bedeutet natürlich, dass Zweige auf einem Remote-Server gelöscht werden

$ git push origin --delete serverfix

Klatschen! Und der Thread auf dem Remote-Server ist verschwunden. Aber im Grunde entfernt dieser Befehl nur den Verzweigungszeiger auf dem Remote-Server. Der Git-Server speichert weiterhin alle Commit-Informationen, bis Sie einen Garbage-Collection-Befehl erteilen.

Remote-Branches sind Verweise auf den Status von Branches 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 (Name des Remote-Vertreters)/(Zweigstelle). Wenn Sie beispielsweise sehen möchten, wie der Master-Zweig auf dem Ursprungsserver aussah, als Sie das letzte Mal eine Verbindung hergestellt haben, sehen Sie sich den Ursprungs-/Master-Zweig an. Wenn Sie und ein Partner an demselben Problem gearbeitet haben und er den iss53-Zweig gepostet hat, können Sie Ihren eigenen lokalen iss53-Zweig haben; aber dieser Zweig auf dem Server zeigt auf das Commit in origin/iss53 .

Das mag alles verwirrend sein, also schauen wir uns ein Beispiel an. Nehmen wir an, Sie haben Ihren eigenen 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 das, worauf der Master-Zweig verweist, und nennt es lokal origin/master (Sie können es jedoch nicht verschieben). Git stellt Ihnen außerdem Ihren eigenen Master-Zweig zur Verfügung, der an derselben Stelle wie der Master-Zweig von Origin 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 einen 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, 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 den Befehl git fetch origin aus. Dieser Befehl sucht nach dem Serverursprung (in unserem Fall ist es git.ourcompany.com); ruft alle Daten ab, 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 Situation mit mehreren Remote-Servern aussehen würden, gehen wir davon aus, dass Sie über einen weiteren internen Git-Server verfügen, 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 als neuen Remote-Link zu dem Projekt hinzufügen, an dem Sie gerade arbeiten, indem Sie den Befehl git remote add auf die gleiche Weise wie in Kapitel 2 beschrieben verwenden. 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 git fetch teamone ausführen, um alles abzurufen, was sich auf dem Server befindet und nicht auf Ihrem. Seit in dieser Moment Dieser Server verfügt nur über einen Bruchteil der Daten des Ursprungsservers. 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 auf die gleiche Weise pushen, wie Sie Ihren ersten Zweig eingereicht haben. Führen Sie Git Push (Remote-Server) aus (Zweig):

$ 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 in gewisser Weise eine 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 davon.“ 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 ausführen – das Gleiche wird passieren – 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 serverfix on heißt Remote-Server, und führen Sie dann anstelle des vorherigen Befehls git push origin serverfix:awesomebranch 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 beim Abrufen neue Remote-Zweige nicht automatisch lokal bearbeitbare Kopien dafür 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 möchten, dass Ihr eigener Serverfix-Zweig funktioniert, können Sie ihn vom 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 mithilfe von git checkout aus einem entfernten Zweig wird automatisch etwas namens „ verfolgter Zweig. Überwachte Zweige sind lokale Zweige, die direkt mit einem Remote-Zweig verbunden sind. Wenn Sie git push eingeben, während Sie sich in einem verfolgten Zweig befinden, weiß Git bereits, an welchen Server und Zweig Änderungen gepusht 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.

Beim Klonen eines Repositorys wird normalerweise 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 die Verfolgung anderer Zweige des Remote-Repositorys konfigurieren. Ein einfaches Beispiel dafür haben Sie gerade gesehen: git checkout -b [branch] [delete. server]/[branch] . Wenn Sie verwenden Git-Versionen 1.6.2 oder höher können Sie auch die Verknüpfung --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 ein Feature fertiggestellt und es in den Master-Zweig auf einem Remote-Server (oder einen anderen Zweig, in dem stabiler Code gespeichert ist) eingefügt. Sie können einen Zweig auf einem Remote-Server löschen, indem Sie die etwas umständliche Syntax git push [delete. server] :[branch] . Gehen Sie wie folgt vor, um den Serverfix-Zweig auf dem Server zu entfernen:

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

Klatschen. Auf Ihrem Server gibt es keinen Branch mehr. Möglicherweise möchten Sie die aktuelle Seite mit einem Lesezeichen versehen, da Sie diesen Befehl benötigen und wahrscheinlich die Syntax vergessen. Sie können sich diesen Befehl merken, indem Sie zur Syntax git push [delete. Server] [lokal. Thread]:[gelöscht branch], den wir uns etwas früher angesehen haben. Teil weglassen [loc. thread] sagen Sie im Wesentlichen: „Nehmen Sie das Nichts in meinem Repository und machen Sie es so, dass es in [gelöscht. Zweig] es war das Gleiche.“