git pull

この図では、リベース プルによって新しい H コミットが作成されていません。代わりに、リベースによってリモート コミット A--B--C がコピーされて、ローカル コミット E--F--G が書き換えられて、ローカルの origin/main コミット履歴に追加されています。

既定の呼び出しと同様に、リモートコンテンツはフェッチされますが、新しいマージコミットは作成されません。

前のプルと同じく、git merge を使用してリモート ブランチをローカル ブランチと統合するのではなく、git rebase を使用します。

プル中に詳細出力が行われ、ダウンロードされているコンテンツとマージの詳細が表示されます。

git pull コマンドは Git における svn update に相当すると考えられます。このコマンドは、ローカル リポジトリを中央リポジトリに同期する簡便な方法です。次の図は、プルを実行したときの各々のステップを説明したものです。

最初はローカル リポジトリが origin と同期されている状態だったものが、git fetch コマンドを実行したことによって、origin の main に最後に確認した時点から進行があったことが明らかになりました。ここで、git merge によってリモート main がローカル main に即時にマージされます。

git pull は、リモート コンテンツの「同期」に関連する多数のコマンドの 1 つです。git remote コマンドは、同期コマンドが実行されるリモート エンド ポイントを指定するために使用されます。git push コマンドは、リモート リポジトリにコンテンツをアップロードするために使用されます。

git fetch コマンドは、git pull と混同されがちです。どちらも、リモート コンテンツのダウンロードに使用されます。git pull と get fetch には安全上の重要な違いがあり、git fetch は「安全」なオプション、git pull は安全ではないオプションと考えられます。git fetch ではリモート コンテンツがダウンロードされ、ローカル リポジトリの状態は変更されません。一方、git pull ではリモート コンテンツがダウンロードされ、そのコンテンツに合わせてローカルの状態の変更が即時に試行されます。これにより、ローカル リポジトリで意図しない競合状態が発生する可能性があります。

--rebase オプションは、不要なマージ コミットを防止することによって直線的な履歴を確保するために使用できます。多くの開発者はマージよりもリベースを優先します。これは、「他のすべての人が行った変更の上に自分の変更を加えたい」と言っているようなものです。その意味では、git pull で --rebase フラグを指定して使用した場合、単純な git pull よりも svn update に似ています。

実際、--rebase フラグを指定したプル操作は非常に一般的なワークフローになっているため、それを行うための専用の設定コマンドが用意されています。

このコマンドを実行すると、すべての git pull コマンドで統合の際に git merge ではなく git rebase が使用されます。

以下の例は、一般的なシナリオで git pull を使用する方法を示しています。

git pull の既定の呼び出しの実行は、git fetch origin HEAD および git merge HEAD に相当します (HEAD は現在のブランチをポイントする参照)。

次の例は、リベースを使用した中央リポジトリの main ブランチと同期する方法を示したものです。

このコマンドを実行すると、他の開発者の作業成果がすべて反映されたものの上にローカルの変更が加えられるようになります。