Git の Pull コマンドの使い方
リモートレポジトリからファイルの最新情報をダウンロードして, ローカルレポジトリ のファイルにマージさせる Git の Pull コマンドの使い方を紹介します.
git pull
コマンドはリモートレポジトリからファイルの最新情報をダウンロードして, ローカルレポジトリのファイルにマージさせて, いわば同期をするためのコマンドです.
お上の方から最新の情報を引っ張ってくるということでプルというわけです.
git pull
は内部的には git fetch
と git merge
を続けて実行するものなので, それら 2 つのコマンドのショートカットのようなものです.
なので git pull
というのは, まず git fetch
で最新情報をリモートからダウンロードし, git merge
でそのダウンロードしたファイルをローカルのファイルにマージさせるという二段階の操作が一度に実行されます.
Pull コマンドの使い方
まず git pull
の基本的な構文は次のようになります:
git pull [<repository> [<refspec>...]]
<repository>
と <refspec>
に渡される値はそのまま git fetch
と git merge
に渡されることになります.
それでは git pull
のそれぞれの使い方を紹介したいと思います.
git pull
単に git pull
とだけ入力すると, 現在チェックアウトしているブランチに設定されている .git/config
の branch.<name>.remote
と branch.<name>.merge
の値が使われます.
これらの設定は git branch --track <branchname> <start-point>
などで設定されるものです.
git clone
で GitHub などにある自分のリモートレポジトリをクローンすると, origin
と refs/heads/master
という値がそれぞれ通常デフォルトで設定されます.
なのでそのような場合 <repository>
や <refspec>
を指定しなくても origin
と master
という値がそれぞれ指定されたことと同じ意味になります.
remote
と merge
の設定がそのように設定された次のようなコミットヒストリの場合 :
A---B---C master on origin
/
D---E---F---G master
^
origin/master
次のコマンドを打つと:
git pull
このようになります:
A---B---C origin/master
/ \
D---E---F---G---H master
E
から分岐していた origin
の master
の先端 C
が, ローカルの master
の先端 G
にマージして H
という新たなコミットが作られました.
このように git pull
を打つまでの origin
の master
は E
だったのですが, git pull
と打ったことによって git fetch
が実行され実は A
, B
, C
と新たなコミットが作られていたという情報をダウンロードし, それらの新しく作られたコミットを G
にマージさせ H
というコミットが作られたというわけです.
参考までに, このコマンドは次のコマンドと同じことをします:
git fetch
git merge
もっと冗長的な同等のコマンドは次のようになります:
git fetch origin master
git merge origin/master
git pull <repository>
<refspec>
<repository>
と <refspec>
を指定すると, それらによって指定されたリモートのコミットを git fetch
し git merge
します.
リモート origin
の master
ブランチをダウンロードし, 現在チェックアウトしているブランチにマージさせる場合, 次のようになります.
git pull origin master
<refspec>
は master
などのブランチに加え, v1.0.0
などのタグを指定することもできます:
git pull origin v1.0.0
git pull –no-commit
--no-commit
オプションを付けると, git pull
によるマージのコンフリクトがない場合でも, マージの失敗を装い, マージしたというコミットを作る前に色々ファイルの内容を確認したり, 修正したりする機会を与えてくれます.
Fast-forward マージの場合は, もともとコミットが作られないので --no-commit
を付けようと意味がありません.
--no-commit
は git merge
のオプションですが, git pull
が git merge
を取り込んでいるからこそこのオプションも使えるのでしょう.
git pull –no-ff
--no-ff
オプションを付けると, git pull
によるマージが fast-forward だとしてもコミットを作ります. (本来 fast-forward のマージはコミットが作られず, HEAD が移動するだけです.)
たとえ fast-forward だとしても, マージしたという記録を残したいときに使えます.
このオプションも git merge
によるものです.
git pull –squash
--squash
オプションを付けると, git pull
によるマージがさも起こったかのように Working Tree と Index の状態を変更します. そして次のコミットでそれらの変更を確定させます.
このオプションもgit merge
によるものです.
git pull –rebase
--rebase
オプションを付けると, git pull
でマージする代わりにリベースします.
git merge
ではなく, git rebase
されるということですね.
次のようなコミットヒストリの場合:
A---B---C master on origin
/
D---E---F---G master
^
origin/master
次のコマンドを入力すると:
git pull --rebase
このようになります:
D---E---A---B---C---F---G master
^
origin/master
このように --rebase
を使うと git rebase
のように E
から分岐した A
, B
, C
を E
の基礎の上に取り込みます.
この状態で git push
とすると次のようになります:
D---E---A---B---C---F---G (master, origin/master)
綺麗なコミットヒストリを構築することができます.
マージした記録を残す必要があまりないような, 少ない規模の変更はこのように --rebase
を付け加えて git pull
をされるといいかと思います.
まとめ
git pull
はリモートレポジトリとローカルレポジトリの状態を一致させるためのコマンドで Git では重要な役割を持っているコマンドです.
git pull
は git fetch
と git merge
のショートカットでもあります.
git pull --rebase
とすると git merge
の代わりに git rebase
になります.
git pull
というコマンドだけで, 現在チェックアウトしているローカルブランチに暗黙的にリモートブランチをマージさせる場合, そのローカルブランチがそのリモートブランチのトラッキングブランチである必要があります.
トラッキングブランチを作る方法は git clone
でリモートブランチをクローンしたり, git checkout -b <branch> --track <remote>/<branch>
などのコマンドを入力する必要があります.
ただ通常はローカルの master
ブランチをリモートの master
ブランチのトラッキングブランチにするということで事足りるのではないかと思いますので, git clone
を入力すると自動的にそうした master
ブランチが作られるので, あまりトラックングブランチを作るということを意識する必要はないのではないかなと思います.
ただこればっかりはケースバイケースだと思いますので, 断定はできないのですが…
ちょっとややこしい説明になってしまい申し訳ありませんでしたが, git pull
の使い方の理解の一助になりましたら幸いです.
最後までお読みくださいましてありがとうございました.
関連記事
git rebase でヒストリを直線的にする方法と使う時の注意点2018.08.13
Git のコミット履歴を大胆に書き換えるなら git rebase -i がオススメ2018.08.23
Git の Push コマンドの使い方2018.06.11
Git のトラッキングブランチの確認と設定方法2018.08.11
git merge オプションの --ff, --no-ff, --ff-only の違い2018.08.15