0

プルがフェッチ + マージであることはどこでもわかります。しかし、ソース ブランチを明示的に指定すると、次のようになります。

(1) git pull origin somebranch

対

(2) git fetch origin somebranch
    git merge origin/somebranch

呼び出し (2) のみがリモート追跡ブランチを更新します。呼び出し (1) は、現在のブランチにマージする前に FETCH_HEAD のみを更新します。どちらの動作も、それぞれのドキュメントと一致しています。それらは互いに一貫していません（ソースブランチが指定されている場合）。

プルの場合、リモート追跡ブランチをスキップする動機は何ですか? リモート追跡ブランチをローカル ブランチの後ろに置きたいのはなぜですか?

1.8.4 のgit-pullマニュアル ページの 2 番目の例では、リモート追跡ブランチが更新されないという動作を確認しています。しかし、それは理由を説明していません。

4

2 に答える 2

1

git fetch1.8.4で の動作が変更されました。現在、明示的に言及された参照は、そのような参照が存在する場合、更新されたローカル追跡参照を持っています。

これは、リリース ノートに記載されている変更です。

トラッキング リファレンスをテストし、現在更新してgit pull origin master いorigin/masterますが、新しい動作と一貫性がありgit fetch origin masterます。

于 2013-11-08T08:11:38.743 に答える
1

「なぜ」の最も賢明な説明は、「ヒステリックなレーズン」、ええと、歴史的理由だと思います。:-)

これは、「git pull origin mybranch」を渡す際に言及され、ローカルの mybranch N コミットが origin より先に残されます。なんで？git pull origin master は origin/masterを更新しませんか? : をgit pull呼び出すと、更新git fetchを防止する引数が渡されます。[編集: Charles Bailey が指摘しているように、この歴史的な奇妙さは 1.8.4 で修正されました。]git fetchrefs/remotes/remote/branchname

ブランチを追跡するためのとへのややぎこちなく複雑なマッピングは、リモート ブランチ ヘッドの更新に失敗する方法のぎこちなさを補完します (それが意味をなす場合:-) )。branch.name.remotebranch.name.mergerefs/remotes/remote/branchgit pull

于 2013-11-08T06:48:01.600 に答える