違いは何ですかgit pullとはgit fetch？

最も単純な用語でgit pullは、のgit fetch後にが続きgit mergeます。

あなたは行うことができますgit fetch下のリモート追跡ブランチを更新するために、いつでもrefs/remotes/<remote>/。

この操作はrefs/heads、の下にある独自のローカルブランチを変更することはなく、作業コピーを変更しなくても安全です。私はgit fetch、バックグラウンドでcronジョブで定期的に実行されている人々についてさえ聞いたことがあります（ただし、これを行うことはお勧めしませんが）。

A git pullは、ローカルブランチをリモートバージョンで最新の状態にし、他のリモート追跡ブランチを更新するために行うことです。

Gitドキュメント– git pull：

デフォルトモードでgit pullは、はのgit fetch後に続く省略形ですgit merge FETCH_HEAD。

• を使用するとpull、Gitは自動的に作業を実行しようとします。状況依存であるため、Gitはプルされたコミットを現在作業中のブランチに pull マージします。最初に確認することなく、コミットを自動的にマージします。ブランチを厳密に管理しないと、頻繁に競合する可能性があります。

• するとfetch、Gitは現在のブランチに存在しないターゲットブランチからのコミットを収集し、ローカルリポジトリに保存します。ただし、現在のブランチとはマージされません。これは、リポジトリを最新の状態に保つ必要があるが、ファイルを更新すると壊れる可能性のある問題に取り組んでいる場合に特に便利です。コミットをマスターブランチに統合するには、を使用しますmerge。

gitの設計哲学とSVNのようなより伝統的なソース管理ツールの哲学を対比することが重要です。

Subversionは、クライアント/サーバーモデルで設計および構築されました。サーバーである単一のリポジトリーがあり、複数のクライアントがサーバーからコードをフェッチして作業し、サーバーにコミットすることができます。操作を実行する必要がある場合、クライアントは常にサーバーに接続できると想定されています。

Gitは、中央リポジトリーを必要とせずに、より分散されたモデルをサポートするように設計されました（ただし、希望する場合は確かに使用できます）。また、gitは、クライアントと「サーバー」が同時にオンラインである必要がないように設計されました。Gitは、信頼性の低いリンクを使用しているユーザーでも、電子メールでコードを交換できるように設計されています。完全に切断された状態で作業し、CDを書き込んでgit経由でコードを交換することができます。

このモデルをサポートするために、gitはコードを含むローカルリポジトリと、リモートリポジトリの状態を反映する追加のローカルリポジトリを維持します。リモートリポジトリのコピーをローカルに保持することにより、gitはリモートリポジトリにアクセスできない場合でも必要な変更を把握できます。後で変更を他の誰かに送信する必要がある場合、gitはそれらを一連の変更としてリモートリポジトリで認識されている特定の時点から転送できます。

• git fetch 「リモートリポジトリのローカルコピーを最新の状態にする」というコマンドです。

• git pull 「リモートリポジトリの変更を、自分のコードを保持する場所に持っていきます。」

通常、git pullこれを行うには、a git fetchを実行してリモートリポジトリのローカルコピーを最新の状態にし、変更内容を独自のコードリポジトリと作業コピーにマージします。

重要なのは、ワークステーションにはプロジェクトのコピーが少なくとも3つあることが多いことを覚えておいてください。1つのコピーは、独自のコミット履歴を持つ独自のリポジトリです。2番目のコピーは、編集および構築する作業コピーです。3番目のコピーは、リモートリポジトリのローカルの「キャッシュされた」コピーです。

ここにあるすべてはそれをすべて一緒にどのように適合するかのオリバースティールの画像は：

十分な関心があれば、画像を更新して追加しgit cloneたり、git merge...

の使用例の1つgit fetchは、最後のプル以降のリモートブランチの変更を次のように伝えます...実際のプルを行う前に確認できるため、現在のブランチと作業コピーのファイルが変更される可能性があります。

git fetch
git diff ...origin

参照：diffコマンドのダブルドットおよびトリプルドット構文については、https：//git-scm.com/docs/git-diff

何が違うのかを理解するのに少し時間がかかりましたが、これは簡単な説明です。masterローカルホストにはブランチがあります。

リポジトリを複製すると、リポジトリ全体がローカルホストにフェッチされます。これは、その時点でHEAD、同じを指すオリジン/マスターポインターとマスターが存在することを意味しますHEAD。

作業を開始してコミットを行うときは、マスターポインターをHEAD+ コミットに進めます。しかし、オリジン/マスターポインターは、クローンを作成したときの状態をまだ指しています。

したがって、違いは次のようになります。

• 実行するgit fetchと、リモートリポジトリ（GitHub）内のすべての変更がフェッチされ、オリジン/マスターポインターがに移動しHEADます。その間、あなたのローカルブランチマスターはそれがどこにあるかを指し示し続けます。
• を実行するとgit pull、基本的にフェッチ（前述のとおり）が行われ、新しい変更がマスターブランチにマージされ、ポインターがに移動しますHEAD。

時には視覚的な表現が役立ちます。

簡単に

git fetchと似てpullいますが、マージされません。つまり、リモート更新（refsおよびobjects）をフェッチしますが、ローカルは同じままです（つまりorigin/master、更新されmasterますが、同じままです）。

git pull リモートからプルダウンし、即座にマージします。

もっと

git clone レポを複製します。

git rebase現在のブランチから上流のブランチにないものを一時的な領域に保存します。これで、ブランチは変更を始める前と同じになります。したがって、git pull -rebaseリモートの変更をプルダウンし、ローカルブランチを巻き戻し、最新の状態になるまで現在のブランチの上から1つずつ変更を再生します。

また、git branch -aローカルとリモートのすべてのブランチで何が起こっているかを正確に示します。

このブログ投稿は役に立ちました：

git pull、git fetch、git clone（およびgit rebase）の違い-Mike Pearce

そしてカバーgit pull、git fetch、git cloneとgit rebase。

====

更新

これを実際にどのように実際に使用するかを示すためにこれを更新すると思いました。

1. リモートからローカルリポジトリを更新します（ただし、マージしないでください）。

   git fetch 
   

2. アップデートをダウンロードしたら、違いを見てみましょう：

   git diff master origin/master 
   

3. これらの更新に満足している場合は、マージします。

   git pull
   

ノート：

ステップ2：ローカルとリモートの差分の詳細については、ローカルgitブランチとリモートブランチを比較する方法を参照してください。

ステップ3：git rebase originここで行う方が、おそらくより正確です（たとえば、変化の速いリポジトリでは）。別の回答で@Justin Ohmsのコメントを参照してください。

参照：http : //longair.net/blog/2009/04/16/git-fetch-and-merge/

git-pull-別のリポジトリまたはローカルブランチからフェッチしてマージする
あらすじ

git pull…
説明

指定されたパラメーターでgit-fetchを実行し、git-mergeを呼び出して 
現在のブランチにヘッドを取得しました。--rebaseを使用して、git-rebaseを呼び出します
git-mergeの代わりに。

を使用できることに注意してください。（現在のディレクトリ）プルする<リポジトリ>として
ローカルリポジトリから-これはローカルブランチをマージするときに役立ちます 
現在のブランチに。

また、git-pull自体と基礎となるgit-mergeを対象としたオプションもあることに注意してください。 
git-fetch用のオプションの前に指定する必要があります。

履歴をマージしたい場合はプルします。この周りの記事にタグを付けている人がいるので、「codezが欲しい」場合はフェッチします。

リモートリポジトリからフェッチし、違いを確認してから、プルまたはマージできます。

これは、リモートリポジトリと呼ばれるoriginブランチとmaster、リモートブランチの追跡と呼ばれるブランチの例ですorigin/master。

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

短くて簡単な答えは、git pull単純にがgit fetch続くことgit mergeです。

が好きかどうかに関わらず自動的にマージされるgit pullことに注意することは非常に重要です。もちろん、これによりマージの競合が発生する可能性があります。あなたのリモコンがoriginで、ブランチがだとしましょうmaster。git diff origin/masterプルする前であれば、マージの競合の可能性についてある程度の知識が必要であり、それに応じてローカルブランチを準備できます。

プルとプッシュに加えて、次のようなワークフローが含まgit rebaseれます。これは、リンクされた記事から言い換えます。

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

このような状況に陥った場合、誘惑に駆られる可能性がありますgit pull --rebase。あなたが本当に、本当にあなたが何をしているかを知らない限り、私はそれに対して助言します。この警告は、バージョンのmanページからのものです：git-pull2.3.5

これは潜在的に危険な操作モードです。それは歴史を書き直しますが、あなたがすでにその歴史を発表したとき、それは良い前兆ではありません。git-rebase（1）を注意深く読んでいない限り、このオプションを使用しないでください。

OK、ここに関するいくつかの情報があるgit pullとgit fetch、あなたは、いくつかの簡単な言葉で、実際の違いを...理解できるように、フェッチ最新のデータを取得しますが、いないコードの変更とあなたの現在のローカル支店コードを台無しにするつもりはないが、プル GETコードが変更され、ローカルブランチにマージされます。それぞれについての詳細を取得するには、以下を読んでください。

git fetch

すべての参照とオブジェクト、および新しいブランチをローカルリポジトリにダウンロードします...

1つ以上の他のリポジトリからブランチやタグ（まとめて「refs」）を、それらの履歴を完成するために必要なオブジェクトとともにフェッチします。リモート追跡ブランチが更新されました（この動作を制御する方法については、以下の説明を参照してください）。

デフォルトでは、フェッチされている履歴を指すタグもすべてフェッチされます。その効果は、関心のあるブランチを指すタグをフェッチすることです。このデフォルトの動作は、-tagsまたは--no-tagsオプションを使用するか、remote..tagOptを構成することで変更できます。タグを明示的にフェッチするrefspecを使用することで、関心のあるブランチを指さないタグもフェッチできます。

git fetchは、指定されたリモートが存在する場合、単一の名前付きリポジトリまたはURL、または一度に複数のリポジトリからフェッチできます。構成ファイルのエントリ。（git-config 1を参照）。

リモートが指定されていない場合、現在のブランチに設定されたアップストリームブランチがない限り、デフォルトで元のリモートが使用されます。

フェッチされた参照の名前は、参照先のオブジェクト名とともに、.git / FETCH_HEADに書き込まれます。この情報は、スクリプトや他のgitコマンド（git-pullなど）で使用される場合があります。

git pull

リモートからローカルの現在のブランチへの変更を適用します...

リモートリポジトリからの変更を現在のブランチに組み込みます。デフォルトモードでは、git pullはgit fetchの後にgit merge FETCH_HEADが続く形式です。

より正確には、git pullは指定されたパラメーターでgit fetchを実行し、git mergeを呼び出して、取得したブランチヘッドを現在のブランチにマージします。--rebaseを使用すると、git mergeではなくgit rebaseが実行されます。

git-fetch 1に渡されるリモートリポジトリの名前である必要があります。任意のリモート参照（たとえば、タグの名前）または対応するリモート追跡ブランチを持つ参照のコレクション（たとえば、refs / heads / ：refs / remotes / origin /）に名前を付けることができますが、通常は名前ですリモートリポジトリのブランチの。

およびのデフォルト値は、git-branch --trackで設定された現在のブランチの「リモート」および「マージ」構成から読み取られます。

以下のビジュアルも作成して、一緒に作業する方法git fetchとgit pull作業方法を示します...

このインタラクティブなグラフィック表現は、gitの理解に非常に役立ちます。http：//ndpsoftware.com/git-cheatsheet.html

git fetchリモートからローカルリポジトリに変更を「ダウンロード」するだけです。git pull変更をダウンロードし、現在のブランチにマージします。「デフォルトのモードでgit pullは、がgit fetch後に続く場合の省略形ですgit merge FETCH_HEAD。」

ボーナス：

上記の回答のプル＆フェッチと言えば、興味深いトリックを共有したいと思います。

git pull --rebase

この上記のコマンドは、私のgitライフで最も便利なコマンドであり、多くの時間を節約しました。

新しいコミットをサーバーにプッシュする前に、このコマンドを実行すると、最新のサーバー変更が自動的に同期され（フェッチ+マージを使用）、コミットがgitログの一番上に配置されます。手動のプル/マージについて心配する必要はありません。

詳細はhttp://gitolite.com/git-pull--rebase

私はこれらの事柄を把握するために状況を視覚的に表現するのが好きです。たぶん他の開発者もそれを見てみたいので、ここに私の追加があります。すべてが正しいかどうかはわかりませんので、間違いがあればコメントしてください。

                                         LOCAL SYSTEM
                  . =====================================================    
================= . =================  ===================  =============
REMOTE REPOSITORY . REMOTE REPOSITORY  LOCAL REPOSITORY     WORKING COPY
(ORIGIN)          . (CACHED)           
for example,      . mirror of the      
a github repo.    . remote repo
Can also be       .
multiple repo's   .
                  .
                  .
FETCH  *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git's distributed nature)
                  .
PULL   *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur, 
you are asked for decisions.
                  .
COMMIT            .                             *<---------------*
When coming from, for example, subversion, you might think that a commit
will update the origin. In git, a commit is only done to your local repo.
                  .
PUSH   *<---------------------------------------*
Synchronizes your changes back into the origin.

リモートのフェッチされたミラーを持つことのいくつかの主な利点は次のとおりです。

• パフォーマンス（ネットワーク経由で絞り込まずに、すべてのコミットとメッセージをスクロールします）
• ローカルリポジトリの状態に関するフィードバック（たとえば、AtlassianのSourceTreeを使用します。これにより、オリジンと比較してコミットが進んでいるか遅れているかを示す電球が表示されます。この情報はGIT FETCHで更新できます）。

私もこれに苦労しています。実際、私はまったく同じ質問のグーグル検索でここに来ました。これらすべての答えを読んで、ようやく頭の中に絵が描かれました。2つのリポジトリと1つのサンドボックスの状態と、それらのバージョンを見ながら時間をかけて実行されたアクションを見て、これを理解することにしました。これが私が思いついたものです。どこかで失敗した場合は修正してください。

フェッチ付きの3つのリポジトリ：

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - fetch               -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     -                     -
- @ R01             -     - @ R01+              -     - @R01+               -
---------------------     -----------------------     -----------------------

プル付きの3つのリポジトリ

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - pull                -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     - merged with R02     -
- @ R01             -     - @ R01+              -     - @R02+               -
---------------------     -----------------------     -----------------------

これは、フェッチが非常に重要である理由を理解するのに役立ちました。

GIT FetchとGIT Pullの違いは、次のシナリオで説明できます：（ 写真は言葉よりも雄弁であることを念頭に置いて！）、図で表現しました）

チームメンバーとプロジェクトに取り組んでいる例を見てみましょう。したがって、彼らはプロジェクトの1つのメインブランチになり、すべてのコントリビューターはそれを自分のローカルリポジトリにフォークし、このローカルブランチでモジュールを変更/追加してからメインブランチにプッシュバックする必要があります。

したがって、 ローカルリポジトリのメインプロジェクトをフォークしたときの2つのブランチの初期状態は次のようになります（A、BおよびCプロジェクトのモジュールはすでに完了しています）。

さて、あなたは新しいモジュールに作業を開始している（としD）、あなたが完了したとき、Dあなたはメインブランチにプッシュするモジュールを、しかし、一方で何が起こるかは、あなたのチームメイトの一つは、新しいモジュールを開発したことがありE、Fそして修正しますC。
つまり、ローカルリポジトリにプロジェクトの元の進捗状況が不足しているため、メインブランチに変更をプッシュすると競合が発生し、モジュールDが誤動作する可能性があります。

このような問題を回避し、プロジェクトの当初の進捗と並行して作業するには、次の2つの方法があります。

1. Git Fetch-これにより、ローカルブランチに存在しないorigin / mainブランチプロジェクトに加えられたすべての変更がダウンロードされます。そして、Git Mergeコマンドがリポジトリまたはブランチにフェッチされた変更を適用するのを待ちます。

これで、ファイルをリポジトリにマージする前に、ファイルを注意深く監視できます。またD、Modifiedのため、必要に応じて変更することもできますC。

2. Git Pull-これにより、ローカルブランチがorigin / mainブランチで更新されます。つまり、実際には、Git FetchとGit mergeが次々に組み合わされます。 ただし、これにより競合が発生する可能性があるため、クリーンコピーでGit Pullを使用することをお勧めします。

私たちは単に言う：

git pull == git fetch + git merge

を実行する場合git pull、データをローカルにマージする必要はありません。を実行する場合、ローカルマシンに最新のコードを取得git fetchするgit mergeために実行する必要があることを意味します。そうしないと、ローカルマシンのコードはマージしないと変更されません。

したがって、Git Guiでは、フェッチを行うときにデータをマージする必要があります。Fetch自体はローカルでコードを変更しません。一度フェッチして確認することで、コードを更新するときにそれを確認できます。変更されないコード。次に、マージします...変更されたコードが表示されます。

git fetchリモートサーバーからローカルリポジトリの追跡ブランチにコードをプルダウンします。リモートに名前が付いている場合origin（デフォルト）、これらの枝は内にあるであろうorigin/例えば、origin/master、origin/mybranch-123、などが挙げられる。これらは、あなたの現在の支店ではありません、彼らはローカルサーバからそれらの枝のコピー。

git pullんgit fetchが、その後もそのブランチのあなたの現在のローカルバージョンに追跡ブランチからコードをマージします。その変更の準備がまだできていない場合は、git fetchまず最初に。

git fetchあなたができるように、リモートブランチを取得しますgit diffかgit mergeそれらの現在のブランチに。git pull現在のブランチによって追跡されているリモート分岐でフェッチを実行し、結果をマージします。を使用git fetchして、ローカルブランチとマージする必要なく、リモートブランチに更新があるかどうかを確認できます。

Gitフェッチ

ローカルブランチへの変更を、originからfetchを介してダウンロードします。Fetchは、他の人が行ったすべてのコミットをリモートリポジトリに要求しますが、ローカルリポジトリにはありません。Fetchはこれらのコミットをダウンロードし、ローカルリポジトリに追加します。

Gitマージ

mergeコマンドを使用して、フェッチによってダウンロードされた変更を適用できます。Mergeはフェッチから取得したコミットを取得して、ローカルブランチに追加しようとします。マージはローカル変更のコミット履歴を保持するため、ブランチをプッシュで共有すると、Gitは他の人がどのように変更をマージできるかを認識します。

Git Pull

フェッチとマージは、2つを組み合わせるコマンドpullが作成されるほど頻繁に一緒に実行されます。プルはフェッチを行ってからマージを行い、ダウンロードしたコミットをローカルブランチに追加します。

唯一の違いgit pullとはgit fetchその次のとおりです。

git pull リモートブランチからプルしてマージします。

git fetch リモートブランチからのみフェッチしますが、マージしません

つまり、git pull = git fetch + git merge ...

簡単に言えば、インターネットに接続せずに飛行機に飛び乗るつもりなら...出発する前に、そうすることができますgit fetch origin <master>。すべての変更をコンピューターにフェッチしますが、ローカルの開発/ワークスペースから分離します。

飛行機では、ローカルワークスペースに変更を加え、それをフェッチしたものとマージし、インターネットに接続せずに潜在的なマージの競合をすべて解決できます。そして、誰かがリモートリポジトリに競合する新しい変更を加えていない限り、目的地に到着しgit push origin <branch>たら、コーヒーを飲みに行きます。

この素晴らしいアトラシアンチュートリアルから：

このgit fetchコマンドは、コミット、ファイル、および参照をリモートリポジトリからローカルリポジトリにダウンロードします。

フェッチとは、他の誰もが取り組んでいることを確認したいときに行うことです。中央の履歴の進行状況を確認できるという点でSVNの更新と似ていますが、実際に変更をリポジトリにマージする必要はありません。Gitはフェッチされたコンテンツを既存のローカルコンテンツから分離します。ローカルの開発作業にはまったく 影響しません。フェッチされたコンテンツは、git checkoutコマンドを使用して明示的にチェックアウトする必要があります。これにより、ローカルリポジトリと統合する前にコミットを確認する安全な方法をフェッチできます。

場合は、リモートリポジトリからコンテンツをダウンロード、git pullおよびgit fetchコマンドは、タスクを達成するために用意されています。git fetch2つのコマンドの「安全な」バージョンを検討でき ます。リモートコンテンツはダウンロードされますが、ローカルリポジトリの動作状態は更新されず、現在の作業はそのまま残ります。git pullより積極的な代替手段です。アクティブなローカルブランチのリモートコンテンツをダウンロードし、すぐに実行git mergeして、新しいリモートコンテンツのマージコミットを作成します。保留中の変更が進行中の場合、これにより競合が発生し、マージ競合解決フローが開始されます。

とgit pull：

• 孤立はありません。
• それはあなたのローカル開発に影響を与えます。
• 明示的にチェックアウトする必要はありません。暗黙的にgit merge。
• 基本的に安全ではありません。それは攻撃的です。
• 異なりgit fetch、それはあなただけの影響を与えるところ.git/refs/remotes、gitのプルが影響するの両方あなた.git/refs/remotes と .git/refs/heads/

うーん...それで、作業コピーをgit fetchで更新しない場合、どこで変更を加えますか？Gitフェッチは新しいコミットをどこに保存しますか？

すばらしい質問です。作業コピーから隔離された場所に配置します。しかし、再びどこに？確認してみましょう。

プロジェクトディレクトリ（つまり、gitコマンドを実行する場所）で次を実行します。

1. ls。ファイルとディレクトリが表示されます。何もかっこいいと思います。

2. さあls -a。これはドットファイルを表示します。つまり、.Youで始まるファイルは、という名前のディレクトリを見ることができます.git。

3. してくださいcd .git。これは明らかにディレクトリを変更します。
4. ここからが楽しい部分です。しますls。ディレクトリのリストが表示されます。探していrefsます。してくださいcd refs。
5. すべてのディレクトリの中に何があるかを見るのは興味深いですが、そのうちの2つに注目しましょう。headsとremotes。cdそれらをチェックするのにも使用します。
6. どれでも git fetchあなたが行うことは、内のアイテムが更新されます/.git/refs/remotesディレクトリを。/.git/refs/headsディレクトリの内容は更新されません。
7. Any git pullは最初にを実行git fetchし、/.git/refs/remotesディレクトリ内のアイテムを更新してから、ローカルとマージしてから、/.git/refs/headsディレクトリ内のヘッドを変更します。

「git fetch」はどこに配置されていますか？。

また、Gitブランチの命名規則の投稿から「スラッシュ表記」を探してください。これは、Gitがさまざまなディレクトリにどのように配置するかをよりよく理解するのに役立ちます。

実際の違いを確認するには

ただやる：

git fetch origin master
git checkout master

リモートマスターが更新された場合は、次のようなメッセージが表示されます。

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

あなたがしなかった場合fetchだけでしたgit checkout master、あなたの地元のgitが追加2つのコミットがあることを知ることはできません。そしてそれはただ言うでしょう：

Already on 'master'
Your branch is up to date with 'origin/master'.

しかし、それは時代遅れで間違っています。それは、gitが知っていることにのみ基づいてフィードバックを提供するからです。まだプルダウンされていないことは、新しいコミットには気づいていません...

ローカルでブランチで作業しているときにリモートで行われた新しい変更を確認する方法はありますか？

一部のIDE（Xcodeなど）は非常にスマートで、aの結果を使用し、git fetch現在の作業ブランチのリモートブランチで変更されたコード行に注釈を付けることができます。その行がローカル変更とリモートブランチの両方によって変更されている場合、その行には赤の注釈が付けられます。これはマージの競合ではありません。これはマージの競合の可能性があります。これgit pullは、リモートブランチから実行する前に、将来のマージの競合を解決するために使用できるヘッドアップです。

楽しいヒント：

リモートブランチをフェッチした場合、たとえば次のようにしました：

git fetch origin feature/123

次に、これはリモートディレクトリに移動します。ローカルディレクトリではまだ利用できません。ただし、DWIMを使用すると、リモートブランチへのチェックアウトが簡単になります（つまり、次のことを行います）。

git checkout feature/123

あなたはもはやする必要はありません：

git checkout -b feature/123 origin/feature/123

詳しくはこちらをご覧ください

Gitでは、新しいコミットの後に、年代順に古いコミットを適用できます。このため、リポジトリ間でコミットを転送する作業は、次の2つのステップに分かれています。

1. リモートブランチからローカルリポジトリ内のこのリモートブランチのコピーに新しいコミットをコピーしています。

   （レポからレポへの操作） master@remote >> remote/origin/master@local

2. ローカルブランチへの新しいコミットの統合

   （内部レポ操作） remote/origin/master@local >> master@local

ステップ2を実行するには2つの方法があります。

1. 最後の共通の祖先の後にローカルブランチをフォークし、ローカルリポジトリに固有のコミットと並行して新しいコミットを追加します。コミットをマージし、フォークを閉じることで確定します。
2. 最後の共通の祖先の後に新しいコミットを挿入し、ローカルリポジトリに固有のコミットを再適用します。

git用語、ステップ1は、git fetchステップ2であり、git merge又はgit rebase

git pullでありgit fetch、git merge

Gitは、次の2つのコマンドを使用して、最新バージョンのブランチをリモートからローカルに取得します。

1. git fetch：Gitはリモートからローカルに最新バージョンを取得しますが、自動的にはマージされません。      git fetch origin master git log -p master..origin/master git merge origin/master

        上記のコマンドは、リモートからオリジンマスターブランチにオリジンからメインブランチの最新バージョンをダウンロードすることを意味します。次に、ローカルマスターブランチとオリジンマスターブランチを比較します。最後に、マージします。

2. git pull：Gitはリモートから最新バージョンを取得し、ローカルにマージします。

       git pull origin master

        上記のコマンドはgit fetchおよびと同等git mergeです。実際git fetchには、マージの前に変更を確認してマージするかどうかを判断できるため、おそらくより安全です。

違いは何であるgit pullとはgit fetch？

これを理解するには、まずローカルgitがローカルリポジトリだけでなく、リモートリポジトリのローカルコピーも保持することを理解する必要があります。

git fetchリモートリポジトリのローカルコピーを最新の状態にします。たとえば、リモートリポジトリがGitHubの場合、リモートリポジトリで行った変更をリモートリポジトリのローカルコピーにフェッチすることができます。これにより、比較やマージなどの操作を実行できます。

git pull一方、リモートリポジトリの変更は、独自のコードを保持する場所に反映されます。通常、git pullはgit fetch最初にリモートリポジトリのローカルコピーを最新の状態にしてから、変更内容を独自のコードリポジトリと作業コピーにマージします。

git pull ==（git fetch + git merge）

git fetchはローカルブランチを変更しません。

目的のプロジェクト用にリモートが設定されたローカルリポジトリがある場合は、git fetchを使用して、既存のリモートのすべてのブランチとタグを取得できます。... Fetchはローカルブランチに変更を加えないため、リモートブランチをペアのローカルブランチとマージして、新しくフェッチした変更を組み込む必要があります。githubから

明確でシンプルであることを目指しています。

gitのプルコマンドは、実際にあるshortcutためにgitのフェッチに続いてgitのマージやgitのリベースの構成に応じてコマンド。Gitリポジトリを構成して、git pullがフェッチとそれに続くリベースになるようにすることができます。

初心者のためのシンプルなグラフィック表現、

ここに、

git pull  

リポジトリからコードをフェッチし、ローカルでリベースします... git pullでは、新しいコミットが作成される可能性があります。

しかし、

git fetch

リポジトリからコードをフェッチし、次を使用して手動でリベースする必要があります git rebase

例：サーバーマスターからフェッチして、ローカルマスターにリベースします。

1）git pull（リベースは自動的に行われます）：

git pull origin master

ここで、オリジンはリモートレポマスター、ブランチです

2）git fetch（手動でリベースする必要があります）：

git fetch origin master

サーバーの変更をオリジンからフェッチします。自分でリベースするまでローカルにあります。コードをチェックして手動で競合を修正する必要があります。

git rebase origin/master

これにより、コードがローカルにリベースされます。その前に、正しいブランチにいることを確認してください。

実際、Gitは独自のコードとリモートリポジトリのコピーを保持しています。

このコマンドgit fetchは、リモートリポジトリからデータを取得することにより、ローカルコピーを最新の状態にします。これが必要な理由は、他の誰かがコードにいくつかの変更を加えた可能性があり、あなたは自分を更新し続けたいと思っているからです。

このコマンドgit pullは、リモートリポジトリの変更を独自のコードを保持する場所に持ってきます。通常、git pullこれを行うには、最初に「git fetch」を実行してリモートリポジトリのローカルコピーを最新の状態にしてから、変更を独自のコードリポジトリと作業コピーにマージします。