GitHub にアップされているブランチをローカルに取り込む

GitHub に限らず、会社や自分で Git のサーバを使った場合にも当てはまりますが、毎回同じことをやっているにも関わらずいちいち調べてるのが面倒になったのでメモしておきます。

photo credit: Ricardo Alguacil via photopin cc

目次

• 1. チェックアウトしたいブランチがローカルに存在しない場合
• 2. ブランチはローカルに存在するが内容が古い場合
• 3. まとめ

1. チェックアウトしたいブランチがローカルに存在しない場合

チェックアウトしたいブランチがローカルに存在しない場合です。
以下は、ブランチ名が v0.4 となっているブランチをチェックアウトする、という想定で書いてます。

まずは、本当に v0.4 のブランチがローカルに存在しないかを確認します。
ローカルに存在するブランチを確認するには git branch を実行します。

$ git branch        
* master
  v0.3.1

確かに v0.4 は存在しませんでした。
ここで一旦、リモートに存在するブランチを確認します（正確には、ネットワーク越しにブランチを確認しているのではないようですが、簡略するためにこのように書きました）。
-r オプションを付けて先ほどの git branch を実行します。

$ git branch -r
  origin/HEAD -> origin/master
  origin/master
  origin/v0.1.1
  origin/v0.2
  origin/v0.3
  origin/v0.3.1
  origin/v0.4

“origin/v0.4″ がありました。

もし、ここで対象となるブランチが表示されなければ、git fetch を実行してリポジトリ情報を最新にしてから、再度 git branch -r を実行します。

というより、作業前は常に git fetch したほうがいいかもしれないですね。
git fetch だけならファイルはマージされないのでコンフリクトの心配はないですし。

$ git fetch
  # ローカルの情報が古ければ、リポジトリ情報がダウンロードされてここに表示されます
$ git branch -r

ちなみに git branch -a とすると、ローカルとリモートのブランチが表示されます。

# git branch -a
* master
  v0.3.1
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/v0.1.1
  remotes/origin/v0.2
  remotes/origin/v0.3
  remotes/origin/v0.3.1
  remotes/origin/v0.4

さて、この v0.4 ブランチをチェックアウトします。
ブランチのチェックアウト方法はいろいろあるようですが、ボクは ↓ のコマンドでチェックアウトしています。

$ git checkout -b ローカルでのブランチ名 チェックアウトするブランチ名

checkout コマンドに -b オプションを付けると、チェックアウト後にそのブランチに切り替わります。
チェックアウト後はそのブランチで作業するので手間が省けます。

「ローカルでのブランチ名」とした部分は、書いたとおりなのですが、ローカルでのそのブランチの名称を指定します。
時間が経って忘れてしまったときにいろいろと面倒なので、リモートと同じブランチ名を指定するのがいいかなと。
わざわざ変更する必要もないでしょうし。

「チェックアウトするブランチ名」の部分は、チェックアウトしたいブランチ名を指定します。
-r オプションを付けて表示されたブランチ名を指定します。

以上を踏まえて、リモートのブランチ origin/v0.4 を v0.4 としてチェックアウトするコマンドは次の通りになります。

$ git checkout -b v0.4 origin/v0.4
Branch v0.4 set up to track remote branch v0.4 from origin.
Switched to a new branch 'v0.4'
$ git branch
  master
  v0.3.1
* v0.4

ブランチ v0.4 がチェックアウトされ、かつ、選択された状態になっています。

2. ブランチはローカルに存在するが内容が古い場合

開発をチームで行ってる場合とか、ボクみたいに自宅と職場で作業している場合とかに発生するパターンがこれに当てはまると思います。
以下は、ブランチ名が work となっているブランチに対する操作になります。

まずはローカルのブランチを確認します。

$ git branch        
  master
  v0.3.1
  v0.4
* work

操作対象のブランチ work が存在し、かつ、選択された状態になっています。

リモートリポジトリの内容をローカルリポジトリに取り込むために git fetch を実行します。

$ git fetch
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From https://github.com/tomoyamkung/googlemap-sample
   54ab40a..587f353  work       -> origin/work

リモートリポジトリに push された work ブランチの最新情報が、ローカルの origin/work ブランチに取り込まれました。

この状態では情報を取り込んだだけでファイルにはマージされていません。
ファイルをマージするには merge コマンドを実行します。

work ブランチのファイルをマージするので、コマンドは git merge origin/work となります。

$ git merge origin/work
Updating 54ab40a..587f353
Fast-forward
 index.html |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index.html に最新情報が反映された旨のメッセージが表示されています。

3. まとめ

会社では Subversion を使っていて、Git は GitHub を使うためにプライベートでしか触っていません。

git fetch をしたたけでファイルが最新の状態に更新されないとか、git fetch したあとに git merge するって何とマージするんだ？みたいなところが全然理解できませんでした。

そこら辺の不明点を次の記事で補ったのでリンクを貼っておきます。
良記事です。

• git fetchの理解からgit mergeとpullの役割 – Qiita