Git Pull vom Master in den Entwicklungszweig

495

Ich habe einen Zweig namens dmgr2 (Entwicklung) und möchte aus dem Hauptzweig (Live-Site) ziehen und alle Änderungen in meinen Entwicklungszweig integrieren. Gibt es einen besseren Weg, dies zu tun? Folgendes hatte ich geplant, nachdem ich Änderungen vorgenommen hatte:

git checkout dmgr2
git pull origin master

Dies sollte die Live-Änderungen in meinen Entwicklungszweig ziehen, oder habe ich das falsch?

git branch pull

— Matthew Colley
quelle

1

Übernehmen Sie zuerst alle Ihre Änderungen im dmgr2-Zweig. und dann auf master zeigen 1.git checkout master und dann die letzte Änderung erhalten 2.git pull 3.git merge dmgr2 4.git push -u origin master Und dann zurück zu deinem dmgr2 5.git checkout dmgr2

— mat_vee

Ich habe bereits alle meine Änderungen an der dmgr2-Verzweigung vorgenommen, leider habe ich vergessen, das hinzuzufügen

— Matthew Colley

1

Wenn ich Schritt 4 ausführe, werden meine Entwicklungsänderungen dann nicht in den Master verschoben? Ich will das nicht tun

— Matthew Colley

Sie sagen also, Sie möchten die Änderungen von Ihrem Hauptzweig in Ihren Entwicklungszweig übernehmen?

— JcKelley

9

Wechseln Sie zu devZweig mit a git checkout dev. Dann git pull --rebase origin master. Wenn Sie Glück haben, gibt es keine Konflikte und der Entwickler hat die neuesten Änderungen vom Master.

— Jww

724

Die von Ihnen aufgelisteten Schritte funktionieren, aber es gibt einen längeren Weg, der Ihnen mehr Optionen bietet:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

Der fetchBefehl kann zu jedem Zeitpunkt vor dem ausgeführt werden merge, dh Sie können die Reihenfolge des Abrufs und des Auscheckens austauschen, da Sie fetcheinfach zur benannten Fernbedienung ( origin) gehen und zu ihr sagen: "Geben Sie mir alles, was Sie haben, was ich nicht habe." ", dh alle Commits in allen Filialen. Sie werden in Ihr Repository kopiert, aber nach origin/branchjedem branchauf der Fernbedienung genannten Zweig benannt .

An dieser Stelle können Sie einen beliebigen Viewer verwenden ( git log, gitkusw.) , um zu sehen „ was sie haben“ , dass Sie dies nicht tun, und vice versa. Manchmal ist dies nur nützlich für warme Fuzzy-Gefühle ("ah, ja, das ist tatsächlich das, was ich will") und manchmal ist es nützlich, um Strategien komplett zu ändern ("whoa, ich will DIESES Zeug noch nicht").

Schließlich mergeübernimmt der Befehl das angegebene Commit, das Sie benennen können origin/master, und unternimmt alles, um dieses Commit und seine Vorfahren in den Zweig zu bringen, in dem Sie sich befinden, wenn Sie das ausführen merge. Sie können einen Schnellvorlauf einfügen --no-ffoder --ff-onlyverhindern oder zusammenführen, wenn das Ergebnis ein Schnellvorlauf ist, wenn Sie möchten.

Wenn Sie die Sequenz verwenden:

git checkout dmgr2
git pull origin master

Der pullBefehl weist git an git fetch, zu rennen , und dann das moralische Äquivalent von git merge origin/master. Das ist also fast das Gleiche wie die beiden Schritte von Hand, aber es gibt einige subtile Unterschiede, die Sie wahrscheinlich nicht allzu sehr betreffen. (Insbesondere der fetchSchritt Lauf durch pullbringt über nur origin/master , und es aktualisiert nicht den Referee in Ihrem Repo: ¹ Alle Commits windet sich durch die besondere bezeichnet zu nur bis FETCH_HEAD. Referenz)

Wenn Sie die explizitere git fetch origin(dann optional umschauende) und dann die git merge origin/masterSequenz verwenden, können Sie auch Ihre eigene lokale masterVersion mit der Fernbedienung auf den neuesten Stand bringen , wobei nur eine fetchüber das Netzwerk ausgeführt wird:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

zum Beispiel.

¹ Dieser zweite Teil wurde in Git 1.8.4 geändert - ich sage "behoben" - und aktualisiert nun "Remote Branch" -Referenzen opportunistisch. (Es war, wie in den Versionshinweisen angegeben, eine bewusste Entwurfsentscheidung, das Update zu überspringen, aber es stellt sich heraus, dass mehr Leute das Git-Update bevorzugen. Wenn Sie den alten Remote-Zweig SHA-1 möchten, wird er standardmäßig gespeichert Dies ermöglicht auch eine neue Git 1.9 / 2.0-Funktion zum Auffinden von Upstream-Rebases.)

— torek
quelle

28

Ich frage nur nach einem Freund - wie würden Sie den ersten Codeblock, den Sie hier haben, rückgängig machen (Auschecken / Abrufen / Zusammenführen)?

— Rich Bradshaw

10

@RichBradshaw: git checkoutist normalerweise zerstörungsfrei und es gibt normalerweise keinen Grund, ein rückgängig zu machen. git fetchEs hört sich also so an, als würden Sie fragen, wie Sie ein Zusammenführungs-Commit zurücksetzen können. Die Antwort ist dieselbe wie bei anderen Commits: entweder git resetoder git revert. Für unveröffentlichte Änderungen git resetist normalerweise die beste Methode; Für Änderungen, die andere bereits vorgenommen haben, ist es git revertvielleicht besser, aber siehe Linus Torvalds Ratschläge zum Zurücksetzen

— torek

2

@WeDoTDD: Ich verstehe die Frage nicht. Es gibt eine Reihe von Befehlen für die grafische Darstellung begehen sehen ( gitk, git log --graphmit oder ohne --oneline, und so weiter) , und Sie können git showoder git show -meine Zusammenführung begehen oder Verwendung git diff. In all diesen Fällen geben Sie das Programm an, wenn Sie den Befehl in der Befehlszeile eingeben.

— Torek

1

@torek: Ich habe versucht,: git checkout branch und dann git pull origin master zu verwenden, aber alle Masteränderungen wurden als einzelne Änderung abgerufen, die erneut lokal festgeschrieben werden sollte, anstatt sie mit ihrem Festschreibungsverlauf und ihren Nachrichten abzurufen, also nach dem Aktualisieren von local Master und Wechsel zum Zweig, "git rebase master" erledigt den Job mit allen zu lösenden Konflikten, und dann füge ich zu "git pull --rebase" hinzu und behandle erneut alle Konflikte, und dann git push origin branch, um alle auszurichten. Ich denke, es sollte einen besseren Weg dafür geben - habe ich recht?

— user10556443

1

@torek: Ich bin damit einverstanden, dass das Ergebnis ein mühsamer Prozess ist, der mich dazu zwingt, das Wiederholen von Rebase & Merge & ... jedes Mal zu verarbeiten, wenn ich ein Update vom Master erhalten möchte ... Aber der vorgeschlagene Weg, den ich zugebe, ist viel einfacher, alle Änderungen unter einer einzigen nicht festgeschriebenen Änderung in der lokalen Niederlassung zu erhalten, ohne die Reihenfolge / den Verlauf des Master-Commits beizubehalten. Ich bin froh, von besseren Vorschlägen zu erfahren, wie man "holen" verwendet und den Master verfolgt, ohne "ziehen" usw. verwenden zu müssen

— user10556443

14

Situation : Ich arbeite in meiner lokalen Niederlassung, aber ich halte mich gerne über Aktualisierungen in der genannten Entwicklungsniederlassung auf dem Laufenden dev.

Lösung : Normalerweise mache ich lieber:

git fetch
git rebase origin/dev

— Greenridinghood
quelle

15

Mit dem üblichen Haftungsausschluss, dass eine Neubasis nur durchgeführt werden sollte, wenn der lokale Zweig nur lokal ist, dh beim Schreiben des Verlaufs nirgendwo hingeschoben wurde.

— Locus

8

Das hat bei mir funktioniert. Um den neuesten Code vom Master in meine Filiale zu bekommen

git rebase origin/master

— Pratik Gaurav
quelle

Vergiss nicht git fetch originzuerst.

— Lenooh

3

Szenario :

Ich habe eine Master-Aktualisierung und eine Zweigaktualisierung. Ich möchte, dass mein Zweig den Master mit Neugründung verfolgt. Um den gesamten Verlauf ordnungsgemäß zu verfolgen, nennen wir meinen Zweig Mybranch

Lösung :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch

Alle Konflikte mit git mergetool &, git rebase --continue, git rebase --skip, git add -u müssen je nach Situation und git-Hinweisen gelöst werden, bis alles gelöst ist

(Korrektur der letzten Stufe mit freundlicher Genehmigung von Tzachi Cohen unter Verwendung von "-f" zwingt git, den Verlauf auf dem Server zu "aktualisieren")

Jetzt sollte der Zweig mit dem Master ausgerichtet und neu basiert werden, auch mit der Remote-Aktualisierung. Im Git-Protokoll gibt es also kein "Zurück" oder "Voraus". Sie müssen lediglich alle lokalen Konflikt * .orig-Dateien entfernen, um den Ordner "sauber" zu halten.

— user10556443
quelle