Git-Pull ohne Checkout?

Ich bin es gewohnt, git pull und andere Befehle innerhalb eines Zweigs auszuführen, an dem ich arbeite. Aber ich habe einen Entwicklungsserver eingerichtet, an dem mehrere Leute arbeiten, also möchte ich dabei nicht die Zweige wechseln müssen. Wenn ich einen bestehenden Zweig auf dem Dev-Server aus dem Github-Repository, das wir alle verwenden, aktualisieren möchte, was wäre der richtige Weg, dies zu tun? Wenn ich den Befehl „git pull github branchname“ ausführe, zieht das einfach den Branch in den aktuellen Branch?

Alle Git-Beispiele, die ich finden kann, scheinen darauf hinzudeuten, dass Sie zuerst „checkout branchname“ ausführen und dann den Pull ausführen. Das versuche ich zu vermeiden. Wie gesagt, dies ist ein bestehender Zweig und ich möchte nur auf die neueste Version aktualisieren.

Ich habe nach demselben gesucht und schließlich die Antwort gefunden, die für mich in einem anderen Stackoverflow-Beitrag funktioniert hat: Merge, update, and pull Git branchs without using checkouts

Grundsätzlich:

git fetch <remote> <srcBranch>:<destBranch>

Ich hatte das gleiche Problem mit der Notwendigkeit, aktuelle Funktionsänderungen zu übernehmen oder zu verstauen, Checkout Meister verzweigen, tun pull Befehl erhalten Sie alles von remote zu lokal master Workspace, wechseln Sie dann erneut zu einem Feature-Branch und führen Sie a rebase um es mit dem Meister auf den neuesten Stand zu bringen.

Um dies alles zu erledigen, halten Sie den Arbeitsbereich im Feature-Zweig und vermeiden Sie das Umschalten. Ich mache Folgendes:

git fetch origin master:master

git rebase master

Und es macht den Trick gut.

Wenn du willst lokal Verzweigungsspitzen, um danach neu ausgerichtet zu werden git fetch, benötigen Sie einige zusätzliche Schritte.

Nehmen wir konkreter an, dass das Github-Repo Zweige hat D, B, C, und master (Der Grund für diesen seltsamen Branch-Namen-Satz wird gleich klar). Sie sind auf Gastgeber devhost und Sie befinden sich in einem Repo, wo origin ist das Github-Repo. Sie machen git fetch, die alle Objekte und Aktualisierungen übernimmt origin/D, origin/B, origin/C, und origin/master. So weit, ist es gut. Aber jetzt sagst du, du willst, dass etwas passiert, weiter devhost, zu lokal Geäst D, B, C, und/oder master?

Ich habe diese offensichtlichen (zumindest für mich) Fragen:

1. Warum willst du die tipps von alle Niederlassungen aktualisiert?
2. Was ist, wenn ein Zweig (z. B. B) hat Commits, die dem entfernten (github) Repo fehlen? Sollen sie zusammengeführt, umbasiert oder … werden?
3. Was ist, wenn Sie in einem Zweig sind (z. B. C) und das Arbeitsverzeichnis und/oder der Index werden geändert, aber nicht festgeschrieben?
4. Was ist, wenn dem Remote-Repo neue Zweige hinzugefügt wurden (A) und/oder Filialen gelöscht (D)?

Wenn die Antwort auf (1) “weil devhost ist eigentlich nicht für die Entwicklung, sondern ein lokaler Spiegel, der einfach eine lokal verfügbare Kopie des Github-Repos aufbewahrt, damit alle unsere eigentlichen Entwickler schnell daraus lesen können, anstatt langsam von Github zu lesen”, dann möchten Sie einen “Spiegel”. anstatt eines “normalen” Repos. Es sollte kein Arbeitsverzeichnis haben und vielleicht auch keine Pushs akzeptieren, in diesem Fall verschwinden die verbleibenden Fragen einfach.

Wenn es eine andere Antwort gibt, wird (2-4) problematisch.

In jedem Fall ist hier eine Möglichkeit, lokale Refs basierend auf Remote-Refs zu aktualisieren (nach dem Ausführen von git fetch -p zum Beispiel):

for ref in $(git for-each-ref refs/remotes/origin/ --format '%(refname)'); do
    local=${ref#refs/remotes/origin/}
    ... code here ...
done

Was geht in die ... code here ... Abschnitt hängt von den Antworten auf die Fragen (2-4) ab.

Benutzen

git fetch

stattdessen. Es aktualisiert die Remote-Refs und -Objekte in Ihrem Repo, lässt aber die lokalen Branches, HEAD und den Worktree allein.