Apullは基本的にfetch（いくつかのコミットと関連オブジェクトをリモートリポジトリからあなたのリポジトリに取得する）であり、次にこれらを作業コピーに「適用」する操作です。デフォルトでは、第2段階はを使用しmergeて実行されますが、pull.rebase変数をに設定するtrueと、代わりにリベースされます。
pullコマンドでポップアップする2つの質問があります。1つ目は、正確に何がフェッチされるのかということです。2つ目は、これらの変更を作業コピーにどのように適用するかです。最初から始めましょう。コマンドの完全な形式は次のとおりです。
git pull [options] [repository] [<refspec>...]
options（作るために例えば--rebase制御動作することをフラグであるpullとして仕事をfetch+rebaseしてもpull.rebaseですfalse）。
repository フェッチ元のリモートの名前（またはURL）です。
refspecs は、リモートでフェッチする参照と、現在の作業コピーのどこにそれらを配置するかを指定する簡潔な方法です。
最初に最も明確な形式を取りましょう。
git pull origin branch1:branch2
これは基本的branch1に、呼び出されたリモートの参照の変更をプルしoriginてから、それらをローカルブランチにマージ（またはリベース）することを意味しbranch2ます。たとえば、と言うとgit pull origin master:dev、とdev同じコミットを指すというローカルブランチが呼び出されmasterます。refspecの指定方法の詳細はこちらです。を使用して、*複数のrefspecを示すことができます。たとえば、git pull origin refs/heads/*:refs/heads/*はすべてのブランチ（の下に格納されているheads）をローカルリポジトリにプルし、それらを同じ名前のローカルブランチにマージします。
それでは、デフォルトがどのように機能するかを説明するために、引数を1つずつ削除してみましょう。まず、refspecから宛先を削除して、単にと言うことができますgit pull origin branch1。これにより、最初fetchにリモートブランチbranch1がローカルリポジトリに移動します。と呼ばれる一時的な参照として利用できるようになりますFETCH_HEAD。その後、実行git merge FETCH_HEADされ、このブランチが現在アクティブなブランチにマージされます（つまりHEAD）。これは、ローカルブランチにいて、リモートからそのブランチに変更をフェッチする場合によく行われます。
さて、branch1完全にドロップして、ただ言ってみましょうgit pull origin。これで、gitは（origin）からどこからフェッチするかはわかりますが、何をフェッチするかはわかりません。これにはいくつかのデフォルトがあります。ほとんどのシナリオは、構成ファイルにbranch.<name>.mergeオプションがある場合です（これはのmergeようなセクション内で呼び出されるエントリです[branch "master"]）。もしそうなら、それは操作のためにそこにあるrefspecsを使用します。
origin完全に削除して単に「」と言うとgit pull、設定をチェックして、branch.<name>.remoteプル元のリモートを指定するが存在するかどうかを確認します。上記と一緒にそれはあなたに何を引っ張るかを教えてくれます。
ポイント4と5は、通常のユースケースではありません。最初の方法は、リモートが呼び出されるorigin/master可能性が低い場合に意味があります。origin/masterで、通常は追跡ローカル参照masterリモートでブランチをorigin。2つ目はHEAD、リモート（通常はデフォルトのブランチ）で変更をフェッチしてから、masterそれらをローカルにマージしようとしますmaster。これはあなたが定期的にやりたいことかもしれませんが、コマンドは非常に型破りで、私が頻繁に使用するものではありません。
いくつかの詳細はスキップしましたが、これらは日常業務で安全で快適に保つのに十分なはずです。厄介な詳細については、のマニュアルページを確認してくださいgit pull。
git pullアップストリームを構成しないとはどういう意味ですか？（マニュアルページには、デフォルトで設定されたアップストリームのみが記載されています。）