Zurücksetzen des Zweigs des lokalen Repositorys auf den des entfernten Repositorys HEAD

Question

Wie setze ich meinen lokalen Zweig so zurück, dass er mit dem Zweig des entfernten Repositorys übereinstimmt?

Das habe ich:

git reset --hard HEAD

Aber wenn ich eine git status ,

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
      modified:   java/com/mycompany/TestContacts.java
      modified:   java/com/mycompany/TestParser.java

Können Sie mir bitte sagen, warum ich sie "geändert" habe? Ich habe diese Dateien nicht angefasst? Wenn ja, möchte ich sie entfernen.

Answer 1

Das habe ich:

git branch -D master
git checkout master

Zweig vollständig zurücksetzen

---

beachten Sie, dass Sie in einen anderen Zweig auschecken sollten, um den gewünschten Zweig löschen zu können

Answer 2

Hier ist ein Skript, das automatisiert, was die beliebteste Antwort vorschlägt ... Siehe https://stackoverflow.com/a/13308579/1497139 für eine verbesserte Version, die Verzweigungen unterstützt

#!/bin/bash
# reset the current repository
# WF 2012-10-15
# see https://stackoverflow.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head
timestamp=`date "+%Y-%m-%d-%H_%M_%S"`
git commit -a -m "auto commit at $timestamp"
if [ $? -eq 0 ]
then
  git branch "auto-save-at-$timestamp" 
fi
git fetch origin
git reset --hard origin/master

Answer 3

Die Antwort

git clean -d -f

unterschätzt wurde ( -d um Verzeichnisse zu entfernen). Danke!

Answer 4

Die bisherigen Antworten gehen davon aus, dass der zurückzusetzende Zweig der aktuelle (ausgecheckte) Zweig ist. In den Kommentaren, OP hap497 geklärt, dass die Verzweigung tatsächlich ausgecheckt ist, was aber in der ursprünglichen Frage nicht ausdrücklich verlangt wird. Da es mindestens eine "doppelte" Frage gibt, Zweig komplett auf Repository-Status zurücksetzen die nicht davon ausgeht, dass der Zweig ausgecheckt ist, gibt es eine Alternative:

Wenn der Zweig "mybranch" ist no derzeit ausgecheckt ist, können Sie ihn auf den Kopf des entfernten Zweigs "myremote/mybranch" zurücksetzen, indem Sie Folgendes verwenden low-level Befehl:

git update-ref refs/heads/mybranch myremote/mybranch

Bei dieser Methode bleibt der ausgecheckte Zweig unverändert und der Arbeitsbaum wird nicht verändert. Sie verschiebt einfach den Kopf von mybranch zu einer anderen Übergabe, die als zweites Argument angegeben wird. Dies ist besonders hilfreich, wenn mehrere Zweige auf neue entfernte Köpfe aktualisiert werden müssen.

Seien Sie dabei jedoch vorsichtig und verwenden Sie gitk oder ein ähnliches Tool, um Quelle und Ziel zu überprüfen. Wenn Sie dies versehentlich auf dem aktuellen Zweig tun (und Git hält Sie nicht davon ab), können Sie verwirrt werden, weil der Inhalt des neuen Zweigs nicht mit dem Arbeitsbaum übereinstimmt, der sich nicht geändert hat (um dies zu beheben, aktualisieren Sie den Zweig erneut, wo er vorher war).

Answer 5

Das verwende ich oft:

git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;

Beachten Sie, dass es eine gute Praxis ist, Änderungen nicht in Ihrem lokalen Master-/Entwicklungszweig vorzunehmen, sondern für jede Änderung in einen anderen Zweig auszuchecken, wobei dem Zweignamen die Art der Änderung vorangestellt wird, z. B. feat/ , chore/ , fix/ , usw. Sie müssen also nur Änderungen ziehen und keine Änderungen von Master pushen. Dasselbe gilt für andere Zweige, zu denen andere beitragen. Die obige Vorgehensweise sollte also nur verwendet werden, wenn Sie zufällig Änderungen in einen Zweig übertragen haben, zu dem andere beigetragen haben, und diese zurücksetzen müssen. Ansonsten vermeiden Sie es in Zukunft, in einen Zweig zu pushen, in den andere pushen, sondern checken Sie aus und pushen Sie in den besagten Zweig über den ausgecheckten Zweig.

Wenn Sie Ihren lokalen Zweig auf den letzten Commit im Upstream-Zweig zurücksetzen wollen, funktioniert das bei mir bisher wie folgt:

Überprüfen Sie Ihre Fernbedienungen und stellen Sie sicher, dass Ihr Upstream und Ihre Herkunft den Erwartungen entsprechen, wenn dies nicht der Fall ist, verwenden Sie git remote add upstream <insert URL> z. B. des ursprünglichen GitHub-Repos, von dem Sie sich abgespalten haben, und/oder git remote add origin <insert URL of the forked GitHub repo> .

git remote --verbose

git checkout develop;
git commit -m "Saving work.";
git branch saved-work;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force

Auf GitHub können Sie auch die Verzweigung mit demselben Namen wie die lokale Verzweigung auschecken, um die Arbeit dort zu speichern, obwohl dies nicht notwendig ist, wenn die ursprüngliche Entwicklungsverzweigung dieselben Änderungen enthält wie die lokale Verzweigung, in der die Arbeit gespeichert wurde. Ich verwende den Zweig develop als Beispiel, aber es kann jeder existierende Zweigname sein.

git add .
git commit -m "Reset to upstream/develop"
git push --force origin develop

Wenn Sie dann diese Änderungen mit einem anderen Zweig zusammenführen müssen, während es irgendwelche Konflikte gibt, behalten Sie die Änderungen in develop bei:

git merge -s recursive -X theirs develop

Während der Verwendung

git merge -s recursive -X ours develop

um die widersprüchlichen Änderungen von branch_name zu erhalten. Andernfalls verwenden Sie ein Mergetool mit git mergetool .

Mit allen Änderungen zusammen:

git commit -m "Saving work.";
git branch saved-work;
git checkout develop;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;
git add .;
git commit -m "Reset to upstream/develop";
git push --force origin develop;
git checkout branch_name;
git merge develop;

Beachten Sie, dass Sie anstelle von upstream/develop auch einen Commit-Hash, einen anderen Branch-Namen usw. verwenden können. Verwenden Sie ein CLI-Tool wie Oh My Zsh, um zu überprüfen, ob Ihr Zweig grün ist, was bedeutet, dass es nichts zu übertragen gibt und das Arbeitsverzeichnis sauber ist (was durch git status ). Beachten Sie, dass dies im Vergleich zur Upstream-Entwicklung zu zusätzlichen Commits führen kann, wenn irgendetwas automatisch durch einen Commit hinzugefügt wird, z.B. UML-Diagramme, Lizenz-Header, usw. In diesem Fall könnten Sie die Änderungen auf origin develop a upstream develop falls erforderlich.