【レシピ本で理解する】 Github/Git 超入門 - 徹底解説（ハンズオンあり）
このシリーズではアナロジーを使った説明中心となっていますが、あくまでもイメージをつかむための例えとなっております。
記事の内容が完全に正しいというわけではありませんのでご了承ください。
公式リンクを随時添付しておりますので、公式の説明も読むことをお勧めします。
今回の【アナロジー解説】シリーズ第3弾は GitHub/Git です。
アナロジーとは、ある事柄を別の似ている事柄に当てはめて理解・説明する「類推（るいすい）」のことです。
はじめに
「新卒でエンジニアになったけど、Git や GitHub をなんとなくしか分かっていない…」
「これからエンジニアを目指して勉強中だけど、Git の概念がふわっとしている」
「先輩との会話で出てくる "PR" "ブランチ" "マージ" の意味、正直ちょっと自信ない」
そんなエンジニア・エンジニア志望の方、いませんか？
そしてエンジニアだけじゃなく、IT 企業で働いている非エンジニアの方々は、エンジニアと会話する場面出てくると思います。そのときに「PR 出しといたよ」「main ブランチに merge したよ」みたいな言葉が飛んできて、「???」となった経験はありませんか？
この記事は、コードを 1 行も書いたことがない人でも、GitHub と Git の仕組みがイメージできるようになることを目指して書きました。最後には GitHub の画面を実際に触ってみるハンズオンもあるので、読み終わる頃には「なんか触ったことあるかも」と思えるはずです。
この記事の対象
- 新卒・若手エンジニアで、Git や GitHub をなんとなく使っている方
- これからエンジニアを目指していて、Git の基本を押さえておきたい方
- IT 企業に勤める非エンジニアで、エンジニアの会話に出てくる用語を理解したい方
- これからチーム開発に関わる予定があり、最低限の共通言語を持っておきたい方
この記事で分かること
- GitHub と Git の違い
- リポジトリ・コミット・ブランチ・Pull Request といった基本用語
- エンジニアが日々どんな流れで開発しているのか
- GitHub の画面を実際に触ってみる体験
GitHub と Git は何が違うの？
最初に一番ややこしいところを片付けてしまいましょう。
- Git: ファイルの変更履歴を記録する「仕組み」そのもの
- GitHub: その Git を使って、みんなで共同作業できるようにした Web サービス
すごくざっくり言うと、Git が「履歴を残せるノート」で、GitHub が「そのノートをみんなで共有できるクラウドサービス」みたいな関係です。Google ドキュメントと Google ドライブの関係に近いかもしれません。
ちなみに GitHub と似たサービスに GitLab や Bitbucket もありますが、世界で一番使われているのが GitHub です。Microsoft が運営しています。
ここでの説明は、初心者の方にイメージをつかんでもらうための個人的な噛み砕き方です。厳密な定義や仕様とは異なる部分もありますので、正確な内容は Git 公式ドキュメント や GitHub Docs も合わせてご確認ください。
この記事のアナロジー: レシピ本
ここから先、GitHub と Git の世界を 「チームでレシピ本を作って改良していく」 という例えで説明していきます。
なぜレシピ本かというと、
- 改訂版が出る（履歴がある）
- 試作レシピを作って、良かったら本に載せる（試行錯誤がある）
- 複数の料理人が関わる（チーム作業）
- 「このレシピどうですか？」と提案する文化がある（レビューがある）
という点が、Git・GitHub の世界と似ているからです。
それでは、用語をひとつずつ見ていきましょう。
リポジトリ = 1 冊のレシピ本
リポジトリ（repository） は、GitHub で一番よく出てくる言葉です。「リポ」と略されることもあります。
レシピ本のアナロジーで言うと、リポジトリは 1 冊のレシピ本まるごと に当たります。
- 表紙（プロジェクト名）
- 目次（README）
- 中身のレシピ（ファイル）
- 改訂履歴（コミットログ）
これら全部をひとまとめにしたものがリポジトリです。
エンジニアが「このリポジトリ見ておいて」と言ったら、「このプロジェクトのファイル一式と履歴が入っている場所を見ておいて」という意味になります。
コミット = 改訂を記録する
コミット（commit） は、ファイルへの変更を「ここまでの状態」として記録する操作です。
レシピ本で言うと、 「ハンバーグのレシピを少し見直したので、改訂として記録しておこう」という作業です。
ポイントは、コミットには メッセージ をつけること。
- 「ハンバーグの塩の量を 1 段階減らした」
- 「カルボナーラに生クリームの代替案を追加」
こんな感じで「何を変えたのか」が一言で分かるメモを残します。これがあるおかげで、後から履歴を見たときに「いつ・誰が・何を変えたか」が一目で分かります。
エンジニアが「とりあえずコミットしといた」と言ったら、「ここまでの変更を記録しておいたよ」という意味です。ファイルを保存するだけでなく、履歴に残るのがコミットの大事なポイントです。
ファイルを上書き保存するのと、コミットすることは別物です。コミットして初めて「過去のバージョンに戻せる」状態になります。
ブランチとマージ = 試作と採用
ここからが Git のおもしろいところです。
ブランチ = 試作用の別バージョン
レシピ本に新しいレシピを載せたいとき、いきなり本書に書き加えるのは怖いですよね。「試作してみて、うまくいったら本に載せる」のが普通です。
これと同じことが Git でもできます。それが ブランチ（branch） です。
ブランチは、本書（メインの本）から枝分かれした「試作用のコピー」だと思ってください。
- メインの本:
mainブランチ（みんなが使う公式の本） - 試作版:
feature/new-curry-recipeブランチ（新作カレーの試作）
試作版で何を変えても、メインの本には影響しません。失敗したらそのブランチごと捨てればいいだけです。
マージ = 試作を本に採用する
試作してみて「これはイケる！」となったら、その変更をメインの本に取り込みます。これが マージ（merge） です。
このやり方のいいところは、
- 試作中もメインの本は壊れない（他の人は安心して使える）
- 複数の試作を同時に進められる（カレー班とパスタ班が並行作業できる）
- 試作が失敗してもメインに影響しない
エンジニアが「ブランチ切るね」と言ったら、「試作用のコピーを作って、そこで作業するね」という意味です。
Pull Request = 「このレシピどうですか？」と提案する
ここが GitHub の主役です。
試作したレシピを いきなり本に載せるのではなく、「このレシピどうですか？ 採用していいですか？」とチームに提案する仕組み が、Pull Request（プルリクエスト、略して PR） です。
PR の流れはこんな感じです。
- 試作ブランチで作業して、いい感じになった
- 「このレシピを本に載せたいです！」と提案を出す（＝ PR を作成）
- 他のメンバーが内容を確認してコメントする（＝レビュー）
- 「ここの分量、もう少し減らしたほうがいいかも」など意見をもらう
- 修正して、OK が出たらメインの本にマージする
エンジニアが「PR 出しといたから見てもらえる？」と言ったら、「変更を提案したのでレビューして欲しい」という意味です。
PR が大事なのは、勝手に main ブランチにマージできない仕組みを作れるから です。誰かのレビューや承認を経ないと本に載らないルールにしておけば、ミスがメインに混入するのを防げます。
「LGTM」という言葉を見たことはありますか？ これは "Looks Good To Me"（私から見て良さそう）の略で、レビューで「OK だよ」と承認するときに使われます。こういった開発時によく使われる英単語について知りたい方は下記の記事を読んでみてください。
リモートとローカル = 出版社の本と手元のコピー
レシピ本がどこに存在するのか、という話です。
- リモート: 出版社にある「公式の本」（＝ GitHub 上のリポジトリ）
- ローカル: 自分の手元にある「コピー本」（＝自分のパソコン上のリポジトリ）
エンジニアは、自分のパソコン（ローカル）で作業して、結果を GitHub（リモート）に送る、という流れで仕事をします。
このやり取りに使う操作が次の 3 つです。
| 操作 | 意味 | レシピ本での例え |
|---|---|---|
| clone | リモートのリポジトリを丸ごとコピーして手元に持ってくる | 公式の本のコピーを 1 冊もらう |
| push | 手元の変更を GitHub に送る | 自分の改訂内容を出版社に送る |
| pull | GitHub から最新版を取ってくる | 最新の改訂版を出版社からもらう |
エンジニアが「pull してから作業して」と言ったら、「最新版を取ってきてから作業を始めて」という意味です。古いバージョンに対して作業すると、後で面倒なことになるからです。
Issue = 「このレシピ作ってほしい」依頼書
Issue（イシュー） は、リポジトリに紐づくタスク管理の仕組みです。
レシピ本で言うと、
- 「夏向けのさっぱりレシピがほしい」（要望）
- 「ハンバーグのレシピで、ソースの分量がおかしい」（バグ報告）
- 「このページの誤字を直したい」（改善提案）
こういう「やりたいこと・直したいこと」を 1 件ずつチケットとして管理する場所です。
PR と Issue の違いは、
- Issue: 「これやりたい」「ここおかしい」という 依頼や報告
- PR: 「やりました、本に載せていいですか」という 完成品の提案
「ここのデザインを直してほしい」「この文言を変えたい」みたいな依頼を Issue として書いておくと、エンジニアが拾って対応してくれる、という運用をしているチームも多いです。
エンジニアと話すときのチートシート
ここまで出てきた用語をまとめておきます。エンジニアの会話で出てきたら、こっそりこの表を見返してください。
| 用語 | 意味 | レシピ本での例え |
|---|---|---|
| リポジトリ | プロジェクトのファイル一式と履歴 | 1 冊のレシピ本 |
| コミット | 変更を履歴に記録する | 改訂を記録する |
| ブランチ | 作業用の分岐 | 試作用の別バージョン |
| マージ | ブランチを統合する | 試作を本に採用する |
| Pull Request（PR） | 変更を提案する仕組み | 「このレシピどうですか？」 |
| レビュー | 提案された変更を確認する | 試作を味見してコメントする |
| Issue | タスクや要望を記録するチケット | 「こんなレシピ作って」依頼書 |
| リモート | GitHub 上のリポジトリ | 出版社にある公式の本 |
| ローカル | 自分のパソコン上のリポジトリ | 手元のコピー本 |
| clone | リモートを手元にコピーする | 本のコピーをもらう |
| push | 手元の変更を GitHub に送る | 改訂を出版社に送る |
| pull | GitHub から最新を取ってくる | 最新の改訂版をもらう |
| main ブランチ | プロジェクトの「正本」となるブランチ | 出版されている公式の本 |
| LGTM | "Looks Good To Me" レビュー OK の合図 | 「これでいいと思います！」 |
ハンズオン: GitHub を実際に触ってみる
ここからは実際に手を動かしてみましょう。コマンドは一切使いません。すべて GitHub の Web 画面だけで完結します。
このハンズオンを進めると、最終的にこちらのようなリポジトリが完成します。先にイメージを掴みたい方はぜひ覗いてみてください。
完成形リポジトリ
レシピ本のアナロジーをそのまま続けて、こんな流れで進めます。
- GitHub アカウントを作る
- 自分のレシピ本（リポジトリ）を作る
- レシピ（README.md）を書いて記録する
- 試作用のブランチを作る
- 試作版で内容を変更する
- Pull Request を出す
- 自分で承認してマージする
所要時間は 15 分くらいです。
Step 1: GitHub アカウントを作る
まず https://github.com/ にアクセスします。
右上の「Sign up」をクリックして、案内に従ってアカウントを作成します。
- メールアドレス
- パスワード
- ユーザー名（半角英数字、後から変更しづらいので慎重に）
を入力していきます。
メールアドレス宛に確認コードが届くので、入力すれば登録完了です。
ログインすると、こんな画面（ダッシュボード）が表示されます。
これで「出版社に登録できた」状態です。
Step 2: 自分のレシピ本（リポジトリ）を作る
画面右上の「+」ボタン → 「New repository」をクリックします。
リポジトリ作成画面で、以下のように入力します。
-
Repository name:
my-recipe-book（好きな名前で OK） -
Description:
レシピ本のサンプル（任意） - Public / Private: Public のままで OK（公開したくなければ Private）
- Add README: チェックを入れる
他はデフォルトのままで大丈夫です。
下の「Create repository」ボタンを押すと、リポジトリが作成されます。
これで「真っさらなレシピ本が 1 冊できた」状態です。
Step 3: レシピ（README.md）を書いて記録する
リポジトリの一覧から README.md をクリックします。
README.md の中身が表示されたら、右上の鉛筆アイコン（Edit this file）をクリックします。
編集画面になるので、好きにレシピを書いてみましょう。例えばこんな感じです。
# 私のレシピ本
## ハンバーグ
- ひき肉 300g
- 玉ねぎ 1個
- パン粉 大さじ2
- 卵 1個
- 塩こしょう 適量
## カルボナーラ
- パスタ 200g
- ベーコン 100g
- 卵 2個
- 粉チーズ 大さじ3
書き終えたら、画面右上の「Commit changes...」ボタンを押します。
コミットメッセージを入力するダイアログが出てくるので、
-
Commit message:
ハンバーグとカルボナーラのレシピを追加 - Commit directly to the main branch を選択
した状態で「Commit changes」を押します。
これで 1 回目のコミット完了 です。「ここまでの状態を本に記録した」イメージですね。
Step 4: 試作用のブランチを作る
次に、試作用のブランチを作ります。
リポジトリのトップに戻って、左上の「main」と書かれたボタンをクリックします。
ブランチの一覧が出てくるので、検索欄に新しいブランチ名を入力します。例えば try/new-curry-recipe と入力すると、「Create branch: try/new-curry-recipe from main」という選択肢が出てくるので、それをクリックします。
これで 試作用のブランチが作成され、自動的にそちらに切り替わります。画面上部のブランチ表示が try/new-curry-recipe に変わっているはずです。
Step 5: 試作版で内容を変更する
切り替わった試作ブランチで、もう一度 README.md を編集してみましょう。
README.md をクリック → 鉛筆アイコンをクリック → 内容にカレーのレシピを追加します。
## カレー（試作）
- 牛肉 300g
- 玉ねぎ 2個
- にんじん 1本
- じゃがいも 2個
- カレールー 1箱
書き終わったら「Commit changes...」を押します。
ダイアログが出てきますが、今回は try/new-curry-recipe ブランチに対して コミットされる状態になっているはずです。コミットメッセージを カレーの試作レシピを追加 にして「Commit changes」を押します。
これで「試作版に変更を加えた」状態です。main ブランチには影響していない のがポイント。リポジトリのトップで main ブランチに切り替えて見てみると、カレーは載っていないことが確認できます。
Step 6: Pull Request を出す
いよいよ PR の出番です。
リポジトリの上部にある「Pull requests」タブをクリックします。
「New pull request」ボタンを押します。
比較画面が出てくるので、
-
base:
main（取り込み先） -
compare:
try/new-curry-recipe（試作ブランチ）
を選びます。
選ぶと、変更内容のプレビューが下に表示されます。「カレーのレシピが追加されている」のが分かるはずです。
問題なければ「Create pull request」ボタンを押します。
PR のタイトルと説明を入力する画面になります。
-
Title:
カレーの試作レシピを追加 - Description: 「カレーのレシピを試作してみました。問題なければ採用してください！」など
最後に「Create pull request」を押すと、PR が作成されます。
これで「このレシピどうですか？」という提案を出した状態になりました。
Step 7: 自分で承認してマージする
本来はチームメンバーがレビューするところですが、今回は 1 人なので自分で承認してマージしてみましょう。
PR 画面の下の方にある「Merge pull request」ボタンを押します。
確認ダイアログが出るので「Confirm merge」を押します。
マージが完了すると、PR が「Merged」状態になります。
リポジトリのトップに戻って main ブランチを見ると、 カレーのレシピが本にも載っている ことが確認できます！
お疲れさまでした！
ここまでの流れで、
- リポジトリを作る
- ファイルを編集してコミットする
- ブランチを作って試作する
- Pull Request で提案する
- マージして本に取り込む
という GitHub の基本的な流れを 1 周体験できました。
エンジニアが日々やっている作業も、本質的にはこの繰り返しです。「PR 出した」「main にマージした」みたいな会話が、ぐっと身近に感じられるんじゃないでしょうか。
おまけ: コマンドラインの世界をちょっとだけ
エンジニアは多くの場合、Web の画面ではなく 黒い画面（ターミナル） でコマンドを打って Git を操作します。今回は触れませんが、雰囲気だけ紹介しておきます。
# リモートのリポジトリを手元にコピー
git clone https://github.com/ユーザー名/my-recipe-book.git
# ファイルを編集したあと、変更を記録
git commit -m "ハンバーグのレシピを修正"
# 手元の変更を GitHub に送る
git push
エンジニアが画面でコマンドを叩いているのを見かけたら、「あ、今 push してるんだな」くらいの解像度でイメージできれば十分です。
おわりに
GitHub と Git は、エンジニアの世界では「水道や電気みたいに当たり前にあるもの」です。なので逆に、知らない人に向けて丁寧に説明される機会が少なく、ふわっとしたまま会話が進んでいることもよくあります。
この記事で、
- リポジトリ・コミット・ブランチ・PR の意味が掴めた
- Web 画面で実際に PR を作ってみる体験ができた
という状態になっていたら嬉しいです。
エンジニアと一緒に仕事をするうえで、共通言語があると会話の質が一気に上がります。「PR 出しといたよ」と言われたとき、「変更を提案してくれたんだな、レビューが必要そうなら確認しようかな」とイメージできるだけでも、コミュニケーションがぐっとスムーズになります。
もし「もう少し触ってみたい！」と思ったら、次のステップは
- 自分のリポジトリで Issue を立ててみる
- 他の人のリポジトリで誤字修正の PR を出してみる（OSS デビュー）
- GitHub Desktop など GUI ツールを使って、自分のパソコンと連携してみる
あたりがおすすめです。
ここまで読んでくださりありがとうございました！
【宣伝】
これまでのアナロジー解説シリーズも是非読んでいただける幸いです！！
また、「この技術について解説して欲しい！」などの要望がありましたら、Xや記事のコメントで気軽にご連絡ください！！