'git pull'と 'git fetch'の違いは何ですか？
モデレータ注：この質問には既に67の回答が投稿されている（一部は削除されている）ので、あなたが新しいものに貢献している別の投稿.
git pullとgit fetchの違いは何ですか？
最も簡単に言うと、git pullはgit fetchに続いてgit mergeを実行します。
git fetchの下でリモートトラッキングブランチを更新するには、いつでもrefs/remotes/<remote>/を実行できます。
この操作はrefs/headsの下であなた自身のローカルブランチを変更することは決してなく、作業コピーを変更せずに変更しても安全です。私はバックグラウンドでcronジョブでgit fetchを定期的に実行している人々のことさえ聞いたことがあります（私はこれをすることを勧めませんが）。
git pullは、ローカルブランチをそのリモートバージョンで最新の状態にしながら、他のリモート追跡ブランチも更新するために行うことです。
Gitドキュメンテーション： git pull
pullを使用すると、Gitは自動的に作業を実行しようとします。 コンテキスト依存なので、Gitはプルされたコミットを現在作業中のブランチにマージします。pull最初に確認せずにコミットを自動的にマージします 。ブランチを厳密に管理しないと、頻繁に競合する可能性があります。fetchを指定すると、Gitは現在のブランチに存在しないコミットをターゲットブランチから収集し、ローカルリポジトリに保存します。ただし、現在のブランチとはマージされません。これは、リポジトリを最新に保つ必要があるが、ファイルを更新すると壊れる可能性のある作業をしている場合に特に便利です。コミットをmasterブランチに統合するには、mergeを使用します。
Gitのデザイン哲学とSVNのようなより伝統的なソース管理ツールの哲学を対比することは重要です。
Subversionはクライアント/サーバーモデルで設計および構築されています。サーバーである単一のリポジトリーがあり、複数のクライアントがサーバーからコードを取り出して作業し、それをサーバーにコミットすることができます。クライアントが操作を実行する必要があるとき、クライアントはいつでもサーバーに連絡できると仮定します。
Gitは、中央のリポジトリを必要とせずに、より分散されたモデルをサポートするように設計されています（ただし、必要に応じて使用することもできます）。また、gitはクライアントと "サーバー"が同時にオンラインになる必要がないように設計されています。 Gitは、信頼できないリンクを使っている人たちでさえ、Eメールでもコードを交換できるように設計されています。完全に切り離された作業をしてgitを介してコードを交換するためにCDを焼くことは可能です。
このモデルをサポートするために、gitはあなたのコードを含むローカルリポジトリと、リモートリポジトリの状態を反映する追加のローカルリポジトリを管理します。リモートリポジトリのコピーをローカルに保存することで、gitはリモートリポジトリにアクセスできない場合でも必要な変更を把握することができます。後で他の人に変更を送信する必要があるとき、gitはリモートリポジトリに知られている時点から変更のセットとしてそれらを転送することができます。
git fetchは、「リモートリポジトリのローカルコピーを最新のものにする」というコマンドです。git pullは "リモートリポジトリの変更を自分のコードを保存する場所に持ってくる"と言っています。
通常git pullは、リモートリポジトリのローカルコピーを最新の状態にするためにgit fetchを実行し、それから変更をあなた自身のコードリポジトリとおそらくあなたの作業コピーにマージすることによって行います。
注意しなければならないのは、少なくとも 3つのコピー /自分のワークステーション上にプロジェクトがあることです。一つのコピーはあなた自身のコミット履歴を持つあなた自身のリポジトリです。 2番目のコピーはあなたが編集して構築しているところのあなたの作業コピーです。 3番目のコピーは、リモートのリポジトリのローカルの「キャッシュされた」コピーです。
git fetchのユースケースの1つは、前回のプル以降にリモートブランチで行われた変更を次のように表示することです。したがって、実際のプルを実行する前に確認できます。
git fetch
git diff ...Origin
違いが何であるかを理解するには少し費用がかかりますが、これは簡単な説明です。あなたのローカルホストのmasterはブランチです。
リポジトリを複製すると、リポジトリ全体をローカルホストに取得します。つまり、その時点ではHEADを指すOrigin/masterポインタと、同じHEADを指すmasterがあります。
作業を開始してコミットすると、マスターポインタをHEAD +自分のコミットに進めます。しかし、Origin/masterポインタは、クローン作成時のものをまだ指しています。
だから違いは次のようになります。
git fetchを実行すると、リモートリポジトリ（ GitHub ）内のすべての変更を取得し、Origin/masterポインタを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をカバーしています。
====
更新
実際にこれを使用する方法を示すために、これを更新したいと思いました。
リモートからローカルレポを更新します（ただしマージはしません）。
git fetchアップデートをダウンロードしたら、違いを見てみましょう。
git diff master Origin/masterこれらのアップデートに満足しているなら、マージしてください。
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-mergeの代わりにgit-rebase を呼び出します。 を使用できます。ローカルリポジトリから を引き出すための<repository>として（現在のディレクトリ） - これはローカルブランチ を現在のブランチにマージするときに便利です。 git-pull自身とその基礎となるgit-merge のためのオプションは、git-fetchのためのオプションの前に与えなければなりません。
履歴をマージしたい場合はプルします。他の人がこの記事の周りにいくつかの記事をタグ付けしているので、単に「codezが必要」の場合はフェッチします。
リモートリポジトリから取得し、違いを確認してからプルまたはマージすることができます。
これは、Originというリモートリポジトリと、リモートブランチOrigin/masterを追跡する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に誘惑されるかもしれません。あなたが本当に、あなたが本当にしていることを本当に知っていない限り、私はそれに対して忠告します。この警告はgit-pull、バージョン2.3.5のmanページからのものです。
これは潜在的に危険な操作モードです。これはの履歴を書き換えますが、既にその履歴を公開したときにはうまくいきません。 git-rebase（1）を熟読していない限り、このオプションを使用しないでください。
_ ok _ 、ここでgit pullとgit fetchに関するいくつかの情報があるので、実際の違いを理解することができます...簡単な言葉で fetch は最新のデータを取得しますがコードは取得しません変更を行っても、現在のローカルブランチのコードをめちゃくちゃにしないでください。 pull コードの変更を取得してローカルブランチにマージしてください。
gitフェッチ
これは、すべての refs および objects と、ローカルリポジトリへの新しいブランチをすべてダウンロードします。
1つまたは複数の他のリポジトリから、それらの履歴を完成するのに必要なオブジェクトと共に、ブランチおよび/またはタグ（まとめて "refs"）を取得します。リモート追跡ブランチが更新されます（この動作を制御する方法については、以下の説明を参照してください）。
デフォルトでは、取得される履歴を指すタグもが取得されます。この効果は、あなたが興味を持っているブランチを指すタグを取得することです。このデフォルトの振る舞いは、 --tagsまたは--no-tagsオプションを使用するか、[。]を設定することによって変更できます。 ____。] remote..tagOpt。タグを明示的にフェッチするrefspecを使用することで、あなたが興味のあるブランチを指していないタグもフェッチすることができます。
git fetchは単一の名前付きリポジトリまたはURLから、あるいはが指定されていてリモートがある場合は一度に複数のリポジトリから取得できます。設定ファイルのエントリ。 （git-config 1 を参照）.
リモートが指定されていない場合、現在のブランチ用に設定されているアップストリームブランチがない限り、デフォルトでOriginのリモートが使用されます。
フェッチされた参照の名前は、それらが指すオブジェクト名と共に、.git/FETCH_HEADに書き込まれます。この情報は、スクリプトやgit-pullなどの他のgitコマンドで使用されることがあります。
git pull
remote から 現在のブランチ localへの変更を適用します。
リモートリポジトリからの変更を現在のブランチに組み込みます。デフォルトモードでは、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で設定されている現在のブランチの "remote"および "merge"設定から読み込まれます。
また、以下の visual を作成して、git fetchとgit pullがどのように連携しているかを説明します。
このインタラクティブなグラフィカル表現は、gitを理解するのに非常に役立ちます。 http://ndpsoftware.com/git-cheatsheet.html
git fetchはリモートからあなたのローカルリポジトリに変更を「ダウンロード」するだけです。 git pullは変更をダウンロードしてそれらを現在のブランチにマージします。 "デフォルトモードでは、git pullはgit fetchの後にgit merge FETCH_HEADがついた略記です。"
ボーナス：
上記の回答の中でpull＆fetchすることに関して言えば、私は興味深いトリックを共有したいと思います、
git pull --rebase
このコマンドは私のgitの人生で最も便利なコマンドで、多くの時間を節約しました。
新しいコミットをサーバにプッシュする前に、このコマンドを試してください。そうすると、最新のサーバの変更が自動的に同期され（フェッチ+マージ）、gitログの一番上にコミットが置かれます。手動のpull/mergeについて心配する必要はありません。
で詳細を見つける： 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.
リモートのフェッチされたミラーを持つことに対するいくつかの大きな利点は以下の通りです。
- パフォーマンス （ネットワークを通して絞らずに、すべてのコミットとメッセージをスクロールする）
- フィードバック あなたのローカルレポの状態について（例えば、私はOriginと比較して先にコミットしているか後ろにコミットしているかを示す電球を私に与えるAtlassianのSourceTreeを使用します。 ）.
私もこれに苦労しました。実際、私は全く同じ質問のグーグル検索でここに来ました。これらすべての答えを読むと、ついに私の頭の中に絵が描かれたので、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つのブランチの Initial Stateは、次のようになります（A、B、およびCは、プロジェクトの完成済みモジュールです）。
さて、あなたは新しいモジュール（Dと仮定します）の作業を始めました、そしてそれをメインブランチにプッシュしたいDモジュールが完成したとき、しかしその間にあなたのチームメイトの一人が新しいモジュールE、Fを開発しましたCを変更しました。
だから今あなたのローカルリポジトリはプロジェクトの最初の進捗状況に遅れているので、メインブランチにあなたの変更をプッシュすることは衝突につながり、あなたのモジュールDを誤動作させるかもしれません。
このような問題を回避し、プロジェクトの当初の進捗と並行して作業するには、次の2つの方法があります。
1. Git Fetch-これはあなたのローカルブランチには存在しないOrigin/mainブランチプロジェクトに加えられたすべての変更をダウンロードします。そしてGit Mergeコマンドがあなたのリポジトリまたはブランチに取得された変更を適用するのを待ちます。
そのため、リポジトリにマージする前にファイルを注意深く監視できます。 Dが変更されているため、必要に応じて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では、フェッチするときにデータをマージする必要があります。フェッチ自体はあなたの地域ではコードを変更しません。一度フェッチしてをフェッチすることでコードを更新したときにそれを確認できます。変更されないコード次にマージします...変更されたコードが表示されます。
git fetchはリモートサーバーからあなたのローカルリポジトリの追跡ブランチへコードを引き下げます。リモートの名前がOrigin（デフォルト）の場合、これらのブランチはOrigin/内になります。例えば、Origin/master、Origin/mybranch-123などです。これらは現在のブランチではなく、サーバーからの local コピーです。
git pullはgit fetchを行います、しかしそれからalsoはトラッキングブランチからのコードをあなたの現在のローカルバージョンのブランチにマージします。まだその変更の準備ができていない場合は、最初にgit fetchを入力してください。
git fetchはリモートブランチを取得するので、現在のブランチでそれらをgit diffまたはgit mergeできます。 git pullは現在のブランチで追跡されているリモートbrachでfetchを実行してから結果をマージします。 git fetchを使用すると、リモートブランチに更新があるかどうかを確認して、それらをローカルブランチとマージする必要がありません。
Git Fetch
あなたはあなたのローカルブランチへの変更をOriginからfetchを通してダウンロードします。 Fetchは他の人が行った全てのコミットをリモートリポジトリにたずねますが、あなたはあなたのローカルリポジトリには持っていません。 Fetchはこれらのコミットをダウンロードしてそれらをローカルリポジトリに追加します。
Git Merge
Mergeコマンドを使用して、取得によってダウンロードされた変更を適用できます。 Mergeは取得したコミットを取得してローカルブランチに追加しようとします。あなたのブランチをPushと共有するとき、Gitは他の人があなたの変更をマージする方法を知るようにマージはあなたのローカルな変更のコミット履歴を保存します。
Git Pull
フェッチとマージは十分に頻繁に一緒に実行され、その2つを組み合わせたコマンドpullが作成されました。プルしてからダウンロードしたコミットをあなたのローカルブランチに追加するためにフェッチしてマージします。
git pullとgit fetchの唯一の違いは、
git pullはリモートブランチから引っ張り出してマージします。
git fetchはリモートブランチからのみ取得しますがマージはしません
すなわちgit pull = git fetch + git merge ...
Gitでは、新しいコミットの後に年代順に古いコミットを適用することができます。このため、リポジトリ間でコミットを転送する動作は2つのステップに分けられます。
リモートリポジトリからこのリモートブランチのコピーへの新しいコミットのコピー。
（リポジトリ操作のリポジトリ）
master@remote >> remote/Origin/master@localローカルブランチへの新しいコミットの統合
（内部レポ操作）
remote/Origin/master@local >> master@local
手順2の実行方法は2つあります。
- 最後の共通の先祖の後でローカルブランチをフォークし、ローカルリポジトリに固有のコミットと並行して新しいコミットを追加します。コミットをマージしてフォークを閉じることで完成します。
- 最後の共通の先祖の後に新しいコミットを挿入し、ローカルリポジトリに固有のコミットを再適用します。
gitという用語では、ステップ1はgit fetch、ステップ2はgit mergeまたはgit rebaseです。
git pullはgit fetchおよびgit mergeです
git pullとgit fetchの違いは何ですか？
これを理解するには、まずあなたのローカルgitがあなたのローカルリポジトリだけでなくリモートリポジトリのローカルコピーも管理していることを理解する必要があります。
git fetchはあなたのリモートリポジトリのローカルコピーを最新にします。たとえば、リモートリポジトリがGitHubの場合 - リモートリポジトリで行った変更を自分のローカルコピーにリモートリポジトリとして取得することができます。これにより、比較やマージなどの操作を実行できます。
一方git pullはリモートリポジトリの変更をあなた自身のコードを保存する場所に持っていきます。通常、git pullは最初にgit fetchを実行してリモートリポジトリのローカルコピーを最新の状態にしてから、変更内容を自分のコードリポジトリと、場合によっては作業コピーにマージします。
Gitは、2つのコマンドを使用して、リモートからローカルへの最新バージョンのブランチを取得します。
git fetch：Gitはリモートからローカルに最新バージョンを取得しますが、自動的にはマージしません。
git fetch Origin mastergit log -p master..Origin/mastergit merge Origin/master上記のコマンドは、Originからメインブランチの最新バージョンをリモートからOriginマスターブランチにダウンロードすることを意味します。次に、ローカルマスターブランチとオリジンマスターブランチを比較します。最後に、マージします。
git pull：Gitはリモートから最新バージョンを取得し、ローカルにマージします。
git pull Origin master上記のコマンドは、
git fetchおよびgit mergeと同等です。実際には、git fetchはおそらくより安全です。なぜなら、マージの前に変更を確認して、マージするかどうかを決定できるからです。
git pull ==（git fetch + git merge）
git fetchはローカルブランチには変わりません。
目的のプロジェクト用にリモート設定されたローカルリポジトリがすでにある場合は、git fetchを使用して既存のリモートのすべてのブランチとタグを取得できます。 ... Fetchはローカルブランチに変更を加えないため、新しく取得した変更を取り込むには、リモートブランチとペアのローカルブランチをマージする必要があります。 githubから
実際にGitはあなた自身のコードのコピーとリモートリポジトリを管理しています。
コマンドgit fetchは、リモートリポジトリからデータを取得することによってローカルコピーを最新の状態にします。これが必要な理由は、他の誰かがコードに何らかの変更を加えた可能性があり、あなたは自分自身を最新の状態に保ちたいからです。
コマンドgit pullは、リモートリポジトリの変更を自分のコードを保存している場所に移動します。通常、git pullは、まずリモートリポジトリのローカルコピーを最新の状態にするために「git fetch」を実行してから、変更内容を自分のコードリポジトリと、場合によっては作業コピーにマージします。
明確かつ単純になろうとしています。
git pull コマンドは、実際には git fetch の後のshortcutname__の後に git merge または git rebase コマンドが続きます。 Gitリポジトリを設定して、 git pull がフェッチとそれに続くリベースになるようにすることができます。
初心者のための簡単なグラフィカル表現
ここに、
git pull
リポジトリからコードを取得し、あなたのローカルでリベースします... git pullで新しいコミットが作成される可能性があります。
でも、
gitフェッチ
リポジトリからコードを取得します。git rebaseを使用して手動でリベースする必要があります。
例：私はサーバーマスターから取得し、私のローカルマスターにそれをリベースしようとしています。
1）git pull（rebaseは自動的に行われます）：
git pull Origin master
here Origin はあなたのリモートレポジトリ master はあなたのブランチです
2）git fetch（手動でリベースする必要があります）：
git fetch Origin master
originからサーバの変更を取得します。そしてそれはあなたがあなた自身でそれをリベースするまであなたのローカルにあります。コードをチェックして手動で競合を修正する必要があります。
git rebase Origin/master
これはコードをローカルにリベースします。その前にあなたが正しいブランチにいることを確認してください。
git pull = git fetch + git merge
From Pro Git§2.5 Gitの基本 - リモコンの操作：自分のリモコンからの取得および取得 ：
fetchコマンドはデータをあなたのローカルリポジトリに引き込むことに注意することは重要です - それは自動的にそれをあなたの仕事のいずれかとマージしたり、あなたが現在取り組んでいるものを変更することはありません。準備が整ったら、手作業で作品にマージする必要があります。リモートブランチを追跡するように設定されたブランチがある場合は、
git pullコマンドを使用して、リモートブランチを現在のブランチに自動的に取得してマージすることができます。これはあなたにとって、より簡単で快適なワークフローかもしれません。デフォルトでは、git cloneコマンドは、複製元のサーバー上のリモートマスターブランチを追跡するようにローカルマスターブランチを自動的に設定します（リモートにマスターブランチがあると仮定）。 。git pullを実行すると、元々複製したサーバーからデータがフェッチされ、自動的にを現在作業中のコードにマージしようとします。
git pull
1つのコマンドで2つの機能を実行します。
リモートブランチに加えられたすべての変更を取得し、それらの変更をローカルブランチにマージします。 --rebaseを渡してpullの動作を変更することもできます。マージとリベースの違いは読むことができます ここ
git fetch
GitフェッチはGit Pullの半分の仕事しかしません。それはあなたのローカルリポジトリにリモートの変更を持ってくるだけであなたのブランチにはそれらを適用しません。あなたは明示的にそれらの変更を適用する必要があります。これは次のようにして行うことができます。
git fetch
git rebase Origin/master
Gitの性質を頭に入れておく必要があります。あなたはリモートとあなたの地元の支店を持っています（必ずしも同じではありません）。他のソース管理システムと比較すると、これは少し複雑です。
通常、リモートをチェックアウトすると、リモートを追跡するローカルコピーが作成されます。
git fetchはリモートブランチと連携してあなたの情報を更新します。
実際には、他のSWEが1つの同じブランチで作業している場合、および1つの小さな開発チーム、1つのプロジェクトで使用されている場合はめったにありません。
地元の支店でのあなたの仕事はまだ無傷です。ローカルブランチに変更を反映させるためには、リモートブランチからの変更をマージ/リベースする必要があります。
git pullはまさにこれら二つのステップを行います（すなわちマージの代わりにリベースするために--rebase）
あなたの地域の歴史と遠隔の歴史が矛盾しているなら、あなたはあなたの変更を公開するためにgit Pushの間にマージをすることを強いられるでしょう。
したがって、それは本当にあなたの職場環境の性質に依存し、何を使うべきかを経験することになります。
git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD
私が理解したことから、
Git pull - 指定されたリモート（ユーザーによって指定された）からプルダウンし、即座に現在のブランチにマージします。基本的にはFetchとMergeコマンドを組み合わせたものです。
Git Fetch - それはPullと同じですが、マージはしません。マージする前にファイルを注意深く監視することができます。
このURLはさらに理解を深めるために役立つはずです： git pull、git fetch、git clone（そしてgit rebase）の違い。
簡単に言えば、
git fetch：新しいものがあるかどうか見てください。
git pull：新しいものを持っていってあなたのものの上に置いてください。
私はほとんどの答えがその違いにかなりよく答えたと信じています。代わりにどちらを使用するかを強調します。
あなたが他の開発者の最新情報を入手する必要があるが、それでもあなたの仕事を妨げられずに続けたい場合には、フェッチは役に立ちます。頻繁にオフラインにして仕事をしたいという人は、彼女がオンラインになるまでfetchを使って最新の更新を入手します。後で彼女/彼女が彼女の変更に慣れてきたら、ブランチからの変更を彼/彼女のワークスペースにマージします。
オンラインで働いていて、彼らの変更を非常に確信していて、最新のコードとmergeをすぐに手に入れたい人はpullを使います。 fetchを使用することはめったにありません。最新のアップデートを確認するには、GitHub Webサイトで確認し、常にオフラインで作業しているからです。私が述べたように、あなたは上記のシナリオのために役に立つかもしれません。
Git Fetch
git repositoryから最新の更新について知らされるのを助けます。 GitFlowname__を使用してチームで作業しているとしましょう。チームは複数のbranchesname__（features）を作業しています。 git fetch --allcommandname__を使えば、branchesname__内のすべての新しいrepositoryname__について知ることができます。
ほとんどのgit fetchはgit resetと一緒に使われます。たとえば、ローカルのすべての変更を現在のリポジトリの状態に戻したいとします。
git fetch --all // get known about latest updates
git reset --hard Origin/[branch] // revert to current branch state
Git pull
このコマンドは、現在のbranchrepositoryname__の状態でbranchname__を更新します。 GitFlowname__から続けましょう。複数のフィーチャーbranchesname__はmergedname__からdevelopname__へのブランチでした。プロジェクトの新しいフィーチャーを開発したい場合は、branchname__を開発してgit pullを実行してdevelopbranchname__の状態にする必要があります
GitFlowのドキュメント https://Gist.github.com/peterdeweese/4251497
Git fetchはリモートリポジトリのカタログをあなたのローカルに同期します。リモートからローカルブランチへのファイル/コードの変更はマージされません。
Git pullはあなたの現在のローカルブランチに関連する変更をダウンロードしてからそれをマージします。
この素晴らしいから アトラシアン チュートリアル：
git fetchコマンドは、コミット、ファイル、および参照をリモートリポジトリからローカルリポジトリにダウンロードします。
すべての人elseが取り組んでいることを確認したい場合は、フェッチを行います。 svn updateと似ていますが、中央の履歴がどのように進行してきたかを見ることができますが、変更を実際にリポジトリにマージすることを強制するものではありません。 Git 取得したコンテンツを既存のローカルコンテンツから分離する 、それは絶対に あなたのローカル開発作業には影響しない 。取得したコンテンツはgit checkoutコマンドを使用して明示的にチェックアウトする必要があります。これにより、コミットをローカルリポジトリに統合する前にコミットをレビューするための安全な方法を取得することができます。
リモートレポジトリからコンテンツをダウンロードするとき、git pullおよびgit fetchコマンドがタスクを実行するために利用可能です。 git fetchは2つのコマンドの「安全な」バージョンと考えることができます。リモートコンテンツはダウンロードされますが、ローカルリポジトリの作業状態は更新されず、現在の作業はそのまま残ります。 git pullはより積極的な代替手段です。アクティブなローカルブランチのリモートコンテンツをダウンロードし、すぐにgit mergeを実行して新しいリモートコンテンツのマージコミットを作成します。保留中の変更が進行中の場合は、これにより競合が発生し、マージ競合解決フローが開始されます。
git pullの場合：
- あなたは孤立することはありません。
- それはあなたの地域の発展に影響を与えます。
- 明示的にチェックアウトする必要はありません。暗黙のうちに
git mergeを実行するからです。 - 基本的に安全ではありません。積極的です。
- あなたの
git fetchだけに影響する.git/refs/remotesとは異なり、git pullはあなたの.git/refs/remotesと.git/refs/heads/の両方にも影響します。
うーん...それで、作業コピーをgit fetchで更新していなければ、どこで変更を加えますか？ git fetchはどこに新しいコミットを保存しますか？
素晴らしい質問です。それはあなたの作業コピーから分離されたどこかにそれを置きます。しかし、ここでも？確認してみましょう。
プロジェクトディレクトリ（gitコマンドを実行する場所）で、次のようにします。
ls。これはファイルとディレクトリを表示します。かっこいい何もない、私は知っている。今
ls -aを行います。これは dotファイル すなわち.で始まるファイルを表示します。そうすると：.gitという名前のディレクトリを見ることができます。cd .gitをしてください。これは明らかにあなたのディレクトリを変更します。- 今楽しい部分が来ます。
lsを実行します。ディレクトリのリストが表示されます。refsを探しています。cd refsをしてください。 - すべてのディレクトリの中身を確認するのは興味深いことですが、そのうちの2つに注目しましょう。
headsおよびremotes。cdを使ってそれらの中もチェックしてください。 git fetchを実行すると、/.git/refs/remotesディレクトリ内の項目が更新されます。/.git/refs/headsディレクトリの内容は更新されません。- すべての
git pullは、最初にgit fetchを実行し、/.git/refs/remotesディレクトリー内の項目を更新してから、ローカルとマージしてから/.git/refs/headsディレクトリー内のヘッドを変更します。
非常に良い関連した答えも見つけることができます 「git fetch」はどこにあるのでしょうか。
Gitブランチの命名規則 postから "Slash notation"も探してください。
答えは、間違いなくgit-pullがgit-fetch plus mergeであることです。私はそれを指摘したいと思います：
マージの前に確認したい場合は、git-fetchに続いてgit-pullを使用する必要があります。
cronjobでは、次のスクリプトに示すように実行すると便利です。
#!/bin/sh
git fetch upstream
if [ `git rev-list HEAD...upstream/master --count` -eq 0 ]
then
echo "all the same, do nothing"
else
echo "update exist, let's pull"
git pull upstream master
git Push Origin master
fi