Frage Kann "git pull" automatisch ausstehende Änderungen speichern und löschen?


Ich weiß, wie ich das lösen kann:

user@host$ git pull
Updating 9386059..6e3ffde
error: Your local changes to the following files would be overwritten by merge:
    foo.bar
Please, commit your changes or stash them before you can merge.
Aborting

Aber gibt es keine Möglichkeit zu lassen? git pull mach das stash und pop Tanz für mich?

Wenn dieser Befehl einen anderen Namen hat, ist es in Ordnung.

Erstellen eines Shell-Alias ​​für git stash; git pull; git stash pop ist eine Lösung, aber ich suche nach einer besseren Lösung.


76
2018-05-13 07:58


Ursprung


Antworten:


Für Git 2.6+ (veröffentlicht am 28. September 2015)

Das einzige git config Einstellung, die von Interesse wäre, ist:

rebase.autoStash

Wenn dieser Wert auf "true" festgelegt ist, erstellen Sie vor Beginn der Operation automatisch einen temporären Stash und wenden Sie ihn nach dem Ende der Operation an.
  Dies bedeutet, dass Sie Rebase auf einem schmutzigen Arbeitsbaum ausführen können.

Verwenden Sie jedoch vorsichtig: Die endgültige Stash-Anwendung nach einer erfolgreichen Umbenennung kann zu nicht-trivialen Konflikten führen. Der Standardwert ist false.

Kombiniere das mit:

pull.rebase

Wenn dies der Fall ist, verzweigt rebase über den abgerufenen Zweig, anstatt den Standardzweig vom Standard-Remote zu verbinden, wenn "git pull" ausgeführt wird.

git config pull.rebase true
git config rebase.autoStash true

Das wäre genug für ein einfaches git pull selbst in einem schmutzigen Baum arbeiten.
In diesem Fall wird kein Alias ​​benötigt.


Sehen commit 53c76dc (04 Jul 2015) von Kevin Daudt (Ikke).
(Zusammengeführt von Junio ​​C Hamano - gitster - im committe e69b408, 17. August 2015) 

pull: erlaube schmutzigen Baum wenn rebase.autostash aktiviert

Rebase hat gelernt, Änderungen zu speichern, wenn es auf einen schmutzigen Arbeitsbaum trifft,   aber git pull --rebase nicht.

Überprüfen Sie nur, ob der Arbeitsbaum schmutzig ist rebase.autostash ist nicht   aktiviert.


Hinweis: Wenn Sie ziehen möchten ohne Autostash (obwohl rebase.autoStash true ist eingestellt), du hast seit git 2.9 (Juni 2016):

 pull --rebase --no-autostash

Sehen commit 450dd1d, commit 1662297, begehe 44a59ff, commit 5c82bcd, commit 6ddc97c, commit eff960b, commit efa195d (02 Apr 2016), und committe f66398e, commit c48d73b (21 Mär 2016) von Mehul Jain (mehul2029).
(Zusammengeführt von Junio ​​C Hamano - gitster - im commit 7c137bb, 13 Apr 2016) 

Commit f66398e insbesondere umfasst:

pull --rebase: hinzufügen --[no-]autostash Flagge

Ob rebase.autoStash Konfigurationsvariable gesetzt ist, gibt es keine Möglichkeit   überschreiben Sie es für "git pull --rebase"von der Befehlszeile aus.

Lehren "git pull --rebase" das --[no-]autostash Befehlszeilenflag welches   überschreibt den aktuellen Wert von rebase.autoStash, falls eingestellt. Wie "git rebase"   versteht das --[no-]autostash Option, es ist nur eine Frage des Bestehens   die Option, zugrunde zu legen "git rebase" wann "git pull --rebase" wird genannt.


Warnung: vor Git 2.14 (Q3 2017), "git pull --rebase --autostash"hat nicht automatisch gespeichert, wenn die lokale Historie schnell zum Upstream geht.

Sehen f15e7cf übergeben (01 Jun 2017) von Tyler Brazier (tylerbrazier).
(Zusammengeführt von Junio ​​C Hamano - gitster - im begehe 35898ea, 05 Juni 2017) 

pull: ff --rebase --autostash arbeitet in schmutzigem Repo

Wann git pull --rebase --autostash in einem schmutzigen Repository führte zu einem   Fast-Forward, nichts war Autostash und der Pull fehlgeschlagen.
  Dies war auf eine Verknüpfung zurückzuführen, um zu vermeiden, dass Rebase ausgeführt wird, wenn wir schnell vorspulen können,   aber Autostash wird auf diesem Codepath ignoriert.


Aktualisieren: Mariusz Pawelski fragt in den Kommentaren eine interessante Frage:

Also schreiben alle darüber autostash wenn du umbugst (oder pull --rebase).

Aber niemand beschäftigt sich mit Autostash, wenn Sie normal mitziehen verschmilzt.
  Also gibt es keinen automatischen Schalter dafür? Oder ich vermisse etwas? Ich bevorzuge es zu tun git pull --rebase aber OP fragte nach "Standard"Ich ziehe

Antworten:

Das Original-Thread Dieses Autostash - Feature diskutiert, wurde ursprünglich für beide implementiert git pull (zusammenführen) und git pull --rebase.

Aber ... Junio ​​C Hamano (Git-Betreuer) bemerkte, dass:

Wenn die pull-merge waren etwas, das den "Ärger" hervorrufen würde   das hat dieses Thema ausgelöst, per Definition überlappt die lokale Änderung   mit der Zusammenführung, und dieser interne "Stash Pop" wird die Wege berühren   die Zusammenführung berührt und es ist wahrscheinlich nicht in "Dropped" führen, sondern verlassen   weitere Konflikte müssen gelöst werden.

Ich vermute, dass pull.autostash Konfiguration ist keine gute Ergänzung, weil es einen schlechten, schmerzauslösenden Workflow fördert.
  In einfachen Fällen mag es nicht weh tun, aber wenn lokale Änderungen komplex sind, würde es aktiv weh tun als nicht, und die Konfiguration beraubt den Anreiz zu wählen.

Die Gleichung ist etwas anders für "Pull-Rebase", wie "Rebase"   besteht darauf, dass Sie von einem sauber arbeitenden Baum starten, also "herunterladen und   dann hör auf "Ärger fühlt sich größer an. Ich habe den Verdacht, dass   Lockerung, die eine produktivere Lösung für das eigentliche Problem sein kann.

In Bezug auf einen klassischen Pull-Merge ist es besser:

Ermutigen Sie den Benutzer, über die Art von WIP nachzudenken, die er im Arbeitsbaum hat, bevor er läuft. "git pull".
  Ist es ein zu komplexes Biest, das sich störend auf das auswirkt, was andere tun?   Ist es eine triviale Veränderung, die er vertuschen und zurückwerfen kann?

Wenn der erste, wird er viel besser dran sein "checkout -b", behalten   arbeiten, bis der lokale Wandel etwas besser in Form kommt und   "commit", bevor Sie in den ursprünglichen Zweig ziehen.

Wenn Letzterer, ist er besser dran zu tun:

  • "git pull",
  • nachdem Sie Konflikte gefunden haben, laufen Sie      
    • git stash,
    • git merge FETCH_HEAD und
    • git stash pop

111
2018-05-13 08:39



Um ein paar Sekunden für kommende Entdecker zu sparen, hier eine Zusammenfassung (Danke an @VonC):

git pull --rebase --autostash

16
2017-08-12 06:27



Wie im obigen Kommentar erwähnt, funktioniert die Einstellung der beiden Konfigurationswerte derzeit nicht git pull, da die Autostash-Konfiguration nur für tatsächliche Rebasts gilt. Diese Git-Befehle tun, was Sie wollen:

git fetch
git rebase --autostash FETCH_HEAD

Oder legen Sie es als Alias ​​fest:

git config alias.pullr '!git fetch; git rebase --autostash FETCH_HEAD'

Dann mach:

git pullr

Natürlich kann dieser Alias ​​beliebig umbenannt werden.


14
2017-07-22 22:56



Mit Git 2.6+ können Sie folgendes verwenden:

alias gup='git -c rebase.autoStash=true pull --rebase'

Dies --rebase macht Git-Pull-Gebrauch rebase Anstatt von merge, also Einstellungen / Optionen mögen --ff-only wird nicht angewendet.

Ich benutze einen Alias, um mit zu ziehen --ff-only standardmäßig (git pull --ff-only), und kann dann verwenden gup (von oben) für den Fall, dass eine Schnellvorlauf-Zusammenführung nicht möglich ist oder es verdeckte Änderungen gibt.


5
2018-04-03 18:18



Wie Sie bereits erwähnt haben, ist dies der richtige Weg. Sie können es im Alias ​​verwenden, um die Eingabe zu speichern und eine Verknüpfung zu verwenden, oder Sie können es in einer einzelnen Zeile verwenden (kann auch ein Alias ​​sein)

git stash && git pull --rebase && git stash pop

Es wird dasselbe wie Sie tun, aber in einer einzigen Zeile (&&) und Sie als Alias ​​festgelegt werden, wird es sogar kürzer sein.

In den folgenden Zeilen werden die eingehenden / ausgehenden Änderungen vor dem Ziehen / Drücken angezeigt

git log ^master origin/master
git log master ^origin/master

1
2018-05-13 08:40