アルパカログ

Gitが初めての人にとって、Gitを使ったバージョン管理の全体像を把握するのは難しいです。

このエントリでは図を多用しながら、Gitの基本となる概念「ブランチ」と「コミット」について説明します。

Gitについて調べると、よくこんな図を目にします。

よく見るあの図

Gitのわかりにくさの1つはこの図にあるのではないか、と私は思っています。

なぜかと言うと、「Gitのリポジトリはローカルとリモートの2種類ある」ことが暗黙の了解になっているからです。

ここで言う「Gitリポジトリ」とは、「ファイルの変更をひとまとめに管理したいプロジェクト」のことだと思ってください。

人によって「レポジトリ」と表記したりもします。英語では repository です。

ローカルとリモート

私たちが作業しているパソコンの環境を、手元にあるという意味で「ローカル」と言い、ローカルにあるリポジトリのことを「ローカルリポジトリ」と言います。

ローカルリポジトリと言うとややこしく聞こえますが、要は作業用フォルダです。

一方、手元のローカルに対して、インターネットを介して離れたところにあるという意味でリモートがあります。

リモートにあるリポジトリのことを「リモートリポジトリ」もしくは単に「リモート」と言います。

リモートリポジトリを提供しているサービスはいろいろあります。

GitHubも、Gitのリモートリポジトリを提供するサービスの1つです。

Gitを使って開発を始めるとき、現在の「コードの状態」を起点にして開発を始めることを「チェックアウト」と言います。

なぜチェックアウトするかと言うと、自分の差分が他と混ざらないようにするためです。

チェックアウトは、木の枝が途中で枝分かれするイメージです。

ですので、チェックアウトすることを「ブランチを切る」と言ったりします（branch: 枝）。

チェックアウトは枝分かれ

チェックアウト時には、枝分かれして新しくできた枝に名前を付けます。

例えば「new-feature-a」（新機能A）など。

この、自分の開発のためにチェックアウトして作った枝ことを「ブランチ」と言います。

枝分かれすることで他の差分と混ざらないようにしているわけですね。

Gitを使って開発を始めるには、最初にブランチをチェックアウトします。

ブランチをチェックアウトするには次の2つのステップを踏みます。

1. リモートリポジトリの更新情報をローカルに取り込む(git fetch)
2. 更新したorigin/masterブランチからブランチをチェックアウトする(git checkout)

古いブランチ情報から開発を始めてしまわないように、まず、リモートリポジトリの更新情報を取り込みローカルのブランチ情報を最新にします。

リモートの更新情報を取得するにはgit fetch originを使います（単にgit fetchでも良いです）。

git fetch のイメージ

ここでoriginというキーワードが出てきました。originは最初にgit cloneした元のリモートリポジトリを指します。

git fetch originはそのまま「元のリモートリポジトリの情報を取得する」ということですね。

リモートのmasterブランチの情報は、ローカルのorigin/masterブランチに反映されます。

次に、origin/masterブランチから機能開発を行うためのブランチ（フィーチャーブランチと言います）をチェックアウトします。

origin/masterブランチからブランチをチェックアウトするにはgit checkout -b ブランチ名 origin/masterとします。

チェックアウトのイメージ

これでリモートにある最新のmasterブランチからチェックアウトすることができました。

Gitのバージョンが2.23以降であれば、git checkout -bの代わりにgit switch -cを使うこともできます。

「コミットする」とは、変更（差分）をGitの履歴に加えることです。

コミットすると、あなたの変更の履歴が「コミット」として記録されます。

コミットのイメージ

しかし追加されたコミットは、この時点ではまだあなたのローカルにしかありません。

変更履歴が他の人からも見えるようにするには、変更履歴を加えたブランチをリモートへアップロードする必要があります。

ローカルのブランチをリモートへアップロードすることを、Gitでは「Pushする」と言います。

当然、ブランチをPushすると同名のブランチがリモートにも存在することになります。

Push のイメージ

これでPull Requestの準備ができました。次はPull Requestの仕組みを見ていきましょう。

ブランチをPushしたことで、コミットはリモートに反映されましたが、まだ正式に採用されてはいません。

なぜなら、リモートのmasterブランチに反映されて初めて正式採用となるからです。*1

誰でも好き勝手に変更を正式採用できてしまうと、バグが潜んでいたり、品質の低いコードになってしまうかもしれません。

そうならないために、「正式採用してくれませんか？」というコミュニケーションの仕組みを提供するのがPull Requestです。

Pull Request のイメージ

Pull Requestは頭文字を取ってPRと呼ばれたり、プルリクと呼ばれたりします。

コードレビューを通してPRがマージされると、あなたの変更がリモートのmasterブランチに反映され、晴れて正式採用となるわけです。

以上です。

このエントリでは、図を多用してGitの「ブランチ」と「コミット」について説明しました。

---

2020年10月8日 origin/masterブランチの所在に関する表記を訂正しました。

• 1:運用によってmasterという名前ではないこともあります。