☰

「git pull」は保留中の変更を自動的に保存およびポップできますか? 質問する

tag-icon • tag-icon git git-pull git-stash
「git pull」は保留中の変更を自動的に保存およびポップできますか? 質問する

これを解決する方法を知っています:

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

git pullでも、をしてstash、私の代わりに踊らせる方法はないのでしょうかpop?

このコマンドの名前が異なっていても問題ありません。

シェルエイリアスを作成することはgit stash; git pull; git stash pop解決策ですが、より良い解決策を探しています。

ベストアンサー1

Git 2.6+ (2015 年 9 月 28 日リリース)

の のみ git config興味深い設定は次のとおりです。

rebase.autostash

（Git 2.27、2020年第2四半期では、merge.autostash、 以下を参照してください）

true に設定すると、操作開始前に一時的なスタッシュが自動的に作成され、操作終了後に適用されます。
つまり、ダーティなワークツリーで rebase を実行できます。

ただし、注意して使用してください。リベースが成功した後の最終的な stash アプリケーションによって、重大な競合が発生する可能性があります。デフォルトは false です。

これを次のものと組み合わせます:

pull.rebase

true の場合、「git pull」の実行時にデフォルトのリモートからデフォルトのブランチをマージするのではなく、フェッチされたブランチの上にブランチをリベースします。

特定のリポジトリの場合:

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

git pull単純なものがダーティ ツリーでも機能するにはこれで十分です。
その場合はエイリアスは必要ありません。

見るコミット 53c76dc(2015年7月4日)ケビン・ダウト ( Ikke)（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット e69b408、2015年8月17日）

pull:rebase.autostash有効にするとダーティツリーを許可する

rebase は、ダーティな作業ツリーに遭遇したときに変更をスタッシュすることを学習しましたが、git pull --rebase実行しません。

rebase.autostash有効になっていない場合にのみ、作業ツリーがダーティであるかどうかを確認します。

注: プルしたい場合はそれなしautostash は（設定されている場合でもrebase.autoStash true）git 2.9（2016 年 6 月）以降で有効です。

 pull --rebase --no-autostash

見るコミット 450dd1d、コミット 1662297、コミット 44a59ff、コミット 5c82bcd、コミット 6ddc97c、コミット eff960b、コミット efa195d（2016年4月2日）コミット f66398e、コミット c48d73b(2016年3月21日)メフル・ジェイン（mehul2029）（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット 7c137bb、2016年4月13日）

コミット f66398e特に以下が含まれます:

pull --rebase:--[no-]autostashフラグを追加

構成変数が設定されている場合、コマンドラインからrebase.autoStash「 」を上書きする方法はありません。git pull --rebase

設定されている場合は、の現在の値を上書きするコマンドライン フラグを" git pull --rebase"に教えます。 " " はオプションを理解するので、 " " が呼び出されたときに、基礎となる " " にオプションを渡すだけです。--[no-]autostashrebase.autoStashgit rebase--[no-]autostashgit rebasegit pull --rebase

警告: Git 2.14 (2017 年第 3 四半期) より前では、git pull --rebase --autostashローカル履歴がアップストリームに早送りされたときに " " は自動的にスタッシュされませんでした。

見るコミット f15e7cf(2017年6月1日)タイラー・ブレイザー ( tylerbrazier)（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット 35898ea、2017年6月5日）

pull: ff は--rebase --autostashダーティリポジトリでも動作します

ダーティなリポジトリで fast-forward が実行されるとgit pull --rebase --autostash、何も自動スタッシュされず、プルが失敗しました。
これは、fast-forward が可能な場合に rebase の実行を回避するためのショートカットによるものですが、そのコードパスでは自動スタッシュは無視されます。

アップデート：マリウス・パウェルスキ尋ねるコメント欄興味深い質問です:

autostashつまり、誰もがrebase (または ) をいつ実行するかについて書いていますpull --rebase。

しかし、通常のプルを実行するときに自動スタッシュについて話している人はいません合併
自動スイッチはないのですか？それとも何か見落としているのでしょうか？私はそうすることを好みますがgit pull --rebase、OPは「標準" git プル

答え：

の元のスレッドこの自動スタッシュ機能について説明すると、これはもともとgit pull(merge) との両方に実装されていましたgit pull --rebase。

しかし... Junio C Hamano (Git メンテナー) は次のように指摘しています:

これがpull-mergeこのトピックを引き起こした「煩わしさ」を引き起こすものである場合、定義上、ローカルの変更はマージと重複し、この内部の「スタッシュ ポップ」はマージが影響したパスに影響し、「ドロップ」にはならず、解決すべきさらなる競合が残る可能性があります。

pull.autostash構成は、悪い、苦痛を伴うワークフローを促進するため、良い追加機能ではないと思います。
単純なケースでは問題にならないかもしれませんが、ローカルの変更が複雑な場合は、構成がないよりも明らかに問題があり、構成によって選択する動機が失われます。

「pull-rebase」の場合は状況が多少異なります。「rebase」ではクリーンな作業ツリーから開始する必要があるため、「ダウンロードして停止する」という煩わしさがより大きくなります。これを緩和することが、実際の問題に対するより生産的な解決策になるのではないかという疑念を抱いています。

したがって、従来のプルマージに関しては、次の方法が最適です。

git pull「 」を実行する前に、作業ツリーにある WIP の性質についてユーザーに考えるように促します。それは他の人の作業を妨げるほど複雑なものでしょうか
、それともしまっておいて元に戻せるような些細な変更なのでしょうか?

checkout -b前者の場合、「 」を実行して、ローカルの変更がいくらか良い形になるまで作業を続けて「コミット」してから、元のブランチにプルする方がはるかに良いでしょう。

後者の場合、次のようにしたほうがよいでしょう。

  • " git pull"、
  • 競合が見つかったら、実行します
    • git stash、
    • git merge FETCH_HEADそして
    • git stash pop

そうは言っても、Git 2.27 (2020 年第 2 四半期) では、" " は、設定が存在せず、も指定されていないgit pull場合 (マージの結果になる) に警告するように学習しました。pull.rebase--[no-]rebase--ff-only

見るコミット d18c950(2020年3月10日)アレックス・ヘンリー（alexhenrie）（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット 1c56d6f、2020年3月27日）

pull: ユーザーがリベースするかマージするかを指定しなかった場合に警告する

署名者: Alex Henrie

多くの場合、初心者の Git ユーザーは「pull --rebase」と言うことを忘れ、アップストリームからの不要なマージを行ってしまいます。

彼らが通常望んでいるのは、pull --rebaseより単純なケースでは「 」、またはメインpull --ff-onlyの統合ブランチのコピーを更新し、作業を個別にリベースする「 」のいずれかです。
構成pull.rebase変数は、より単純なケースで彼らを助けるために存在しますが、これらのユーザーにそれを認識させるメカニズムはありません。

--[no-]rebaseコマンドラインからオプションが指定されず、pull.rebase設定変数も指定されていない場合は、警告メッセージを発行します。
これは、" " をまったく使用したくない、特別な操作をする必要のないユーザーにとっては不便ですpull --rebaseが、この不便さのコストはユーザーごとに 1 回だけ発生するため、多くの新規ユーザーを支援するには妥当なコストです。

Git 2.27 (2020 年第 2 四半期) では、「git merge」は「--autostash」オプションと新しいmerge.autostash設定を学習します。

見るコミット d9f15d3、コミット f8a1785、コミット a03b555、コミット 804fe31、コミット 12b6e13、コミット 0dd562e、コミット 0816f1d、コミット 9bb3dea、コミット 4d4bc15、コミット b309a97、コミット f213f06、コミット 86ed00a、コミット facca7f、コミット be1bb60、コミット efcf6cf、コミット c20de8b、コミット bfa50c2、コミット 3442c3d、コミット 5b2f6d9(2020年4月7日)コミット 65c425a（2020年4月4日）コミット fd6852c、コミット 805d9ea(2020年3月21日)デントン・リュー ( Denton-L)（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット bf10200、2020年4月29日）

pull: マージするには --autostash を渡す

署名者: Denton Liu

以前は、--autostashのみで動作していましたgit pull --rebase。

ただし、最後のパッチでは、マージ--autostashも学習したため、この制限を設ける必要はなくなりました。
--autostashリベースの場合と同様に、マージするにはpull に pass を教えるようにします。

そして：

rebase:apply_autostash()シーケンサー.cから使用

署名者: Denton Liu

apply_autostash()の機能builtin/rebase.capply_autostash()の機能とよく似ているsequencer.c受け入れる引数の型を除けば、それらはほぼ互換性があります。sequencer.cバージョンを extern にして、リベースで使用します。

リベースバージョンは6defce2b02("組み込みリベース: サポート--autostashオプション", 2018-09-04, Git v2.20.0-rc0 --マージ記載されているバッチ #8）をシェルからCへの変換の一部として
追加しました。当時、シェルからCへのインタラクティブリベースを変換する別のプロジェクトが進行中であり、リファクタリングによってそれらと衝突することを望まなかったため、関数を複製することを選択しました。sequencer.cのバージョンですapply_autostash()。
両方の取り組みは長い間行われてきたので、今では自由に組み合わせることができます。

Git 2.30 (2021年第1四半期) では、UI が改善されました。

見るコミット e01ae2a(2020年11月19日)ヨハネス・シンデリン（dscho）（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット 290c940、2020年11月30日）

pull: 設定に関するヒントを色分けするpull.rebase

指摘者: Ævar Arnfjörð Bjarmason
署名者: Johannes Schindelin

でd18c950a69f(" pull: ユーザーがリベースするかマージするかを指定しなかった場合に警告する", 2020-03-09, Git v2.27.0-rc0 --マージ記載されているバッチ #2)、設定を構成することで、プルをマージするかリベースするかをユーザーが意識的に決定できるようにするための新しいヒントが導入されましたpull.rebase。

この警告は明らかにユーザーへのアドバイスを目的としていたが、このスレッド、warning()の代わりにを使用しますadvise()。

その結果、アドバイスは他の同様のメッセージと同じように色分けされません。代わりに
を使用しましょうadvise()。

Git 2.33 (2021年第3四半期) では、次のgit pull --rebase点が簡素化されています。

見るコミット a7d18a1、コミット a751e02、コミット 3400622(2021年6月17日)フェリペ・コントレラス ( felipec)（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット 221ec24、2021年7月8日）

pull: クリーンアップ自動スタッシュチェック

署名者: フェリペ・コントレラス

現在 "git pull --rebase「（男) は、早送りマージが可能な場合にショートカットを実行し、run_merge()--ff-only で呼び出されます。

しかし、 "git merge「（男）には選択肢がなかったので--autostash、「git プル--rebase--autostash``「（男）と呼ばれていましたそして早送りマージのショートカットが実行され、プルが失敗しました。

これは修正されましたコミット f15e7cf(" pull: ff --rebase--autostash はダーティリポジトリでも動作します", 2017-06-01, Git v2.14.0-rc0 --マージ記載されているバッチ #7) は、早送りマージのショートカットをスキップするだけで実行できます。

その後、「git merge」はオプションを学んだ--autostash[a03b555(" merge: ティーチ--autostashオプション", 2020-04-07, Git v2.27.0-rc0 --マージ記載されているバッチ #5)]、そして「git pull「（男) [d9f15d3(" pull:--autostashマージに渡す", 2020-04-07, Git v2.27.0-rc0 --マージ記載されているバッチ #5)]。

したがって、 で呼び出されたときに、早送りマージのショートカットをスキップする必要はなくなりました--rebase --autostash。

基本的に元に戻すことで、常に早送りマージのショートカットを使いましょう翻訳:。

「git merge --autostash「（男) が作業ツリーに残された競合状態に混在していましたが、これは Git 2.38 (2022 年第 3 四半期) で修正されました。

見るコミット d3a9295(2022年8月23日)イライジャ・ニューレン（newren）（合併者：
ジュニオ・C・ハマノ -- gitster--でコミット 3a47790、2022年9月1日）

merge: 適切な場合にのみ自動スタッシュを適用する

署名者: Elijah Newren

マージが失敗し、ユーザーが解決できるように作業ディレクトリに競合が残っている場合は、自動スタッシュを適用しないでください。

さらに、自動スタッシュの適用に失敗した場合（マージが失敗したか、ユーザーが を要求したため--no-commit）、後でそれを適用する方法をユーザーに指示する必要があります。

この動作が修正されたことを確認するテストケースを追加します。

新しい指示:

完了したら、 で保存した変更を適用しますgit stash pop。

おすすめ記事