【新卒向け】GitHubの使い方 - 初めてのバージョン管理

なぜバージョン管理が必要なのか

想像してほしい。共有フォルダに「報告書_最終版.zip」「報告書_最終版_v2.zip」「報告書_最終版_v2_修正済_最新.zip」が並んでいる光景を。どれが本当に最新なのか誰にも分からず、上書きで誰かの修正が消え、「先週の状態に戻したい」と思っても戻せない——ファイルのコピーを履歴の代わりにする運用は、必ずこの地獄に行き着く。

ソフトウェア開発ではこの問題がさらに深刻になる。数百のファイルを複数人が同時に編集し、しかも「どの時点のファイルの組み合わせなら動いていたか」が重要になるからだ。バージョン管理システムは、この問題を3つの機能で解決する。

1. 履歴の記録 — 誰が・いつ・どのファイルを・なぜ変更したかをすべて残す
2. 復元 — 任意の過去時点のプロジェクト全体を正確に再現する
3. 並行作業の合流 — 複数人の変更を安全に1つにまとめる

Gitは、このバージョン管理システムの事実上の世界標準だ。

GitとGitHubは別物

初心者が最初に混同するのがここだ。

• Git — 自分のPCの中で動くバージョン管理ツール。履歴の記録・復元・分岐はすべてローカルで完結し、ネットワークがなくても動く
• GitHub — Gitで管理された履歴一式（リポジトリ）をインターネット上で預かるホスティングサービス。加えて、Pull Requestによるコードレビュー、Issueによるタスク管理といった「チーム開発の場」を提供する

たとえるなら、Gitは文書の変更をすべて記録する台帳で、GitHubはその台帳の写しを保管・共有する図書館にあたる。後で出てくるPull RequestはGitのコマンドではなくGitHubの機能である、という区別は覚えておいてほしい（同種のサービスにGitLabやBitbucketもある）。

Gitのメンタルモデル

コマンドを打つ前に、Gitが内部で何を管理しているかを押さえる。ここを飛ばすと、コマンドはただの呪文の暗記になってしまう。

commit = プロジェクト全体のスナップショット写真

コミットとは「その瞬間のプロジェクト全ファイルを丸ごと写した写真」だ。変更差分のメモではなく全体のスナップショットであり、各コミットは直前のコミット（親）を指している。だから履歴は鎖のようにつながる。

A --- B --- C   (time goes right)

過去に戻りたければ、鎖をたどってBの写真を取り出せばいい。これが「復元」の正体だ。

branch = 作業の並行世界

ブランチは、コミットの鎖の先端に貼られた「動くラベル」だ。新しいブランチを作ると、そこから先の歴史が分岐し、並行世界のように独立して進められる。

              D --- E   (feature/greeting)
             /
A --- B --- C           (main)

main（チームの正式な歴史）に触れずに自分の作業を進め、完成してから合流（マージ）する。これが「並行作業の合流」の正体だ。

push / pull = ローカルとリモートの同期

cloneすると、GitHub上のリポジトリ（リモート）の完全なコピーが自分のPC（ローカル）にできる。以後、両者は独立した存在で、自動では同期しない。

[GitHub (remote)]  <-- push --  [your PC (local)]
                   -- pull -->

• push — ローカルで積んだコミットをリモートへ送る
• pull — リモートに増えたコミットをローカルへ取り込む

もうひとつ: ステージングエリア

Gitの中でファイルは3つの場所を通る。「作業ツリー（編集中の実ファイル）→ ステージ（次の写真に写す物を並べる台）→ リポジトリ（撮影済みの写真棚）」。git add はステージに載せる操作、git commit は撮影だ。ステージがあるおかげで、「直した10ファイルのうち、意味のまとまりがある3ファイルだけを1枚の写真にする」ことができる。

最小ワークフローを1本のストーリーで

チームのリポジトリに、あいさつスクリプトを1つ追加する——という体でひととおり流す。各ステップは「何をする → なぜ必要 → 実行例 → 結果の確認」の順で読んでほしい。

1. clone — リモートの複製を手元に作る

リポジトリの全履歴を自分のPCへ複製する。ローカルに完全なコピーがなければ、そもそも編集もコミットもできない。

git clone https://github.com/example-team/onboarding.git
cd onboarding

確認: git log --oneline -5 で直近の履歴が表示されれば成功だ。

2. branch — 並行世界を開く

git switch -c feature/add-greeting

-c は「作成して移動」。mainを直接編集しないのは、レビュー前の変更をチームの正式な歴史から隔離するためだ。確認: git branch で現在いるブランチに * が付く。

なお、古い資料にある git checkout -b は同じ意味の旧コマンドだ。

3. 編集して、状態を見る

# greeting.py
def greet(name: str) -> str:
    # Return a simple greeting message
    return f"Hello, {name}!"

編集したら必ず git status。Gitとの対話で最も頻繁に打つコマンドで、「今どのファイルがどの段階にあるか」を教えてくれる。変更内容そのものは git diff で確認する。

4. add — 写真に写す物を選ぶ

git add greeting.py
git status    # confirm the file is under "Changes to be committed"

なぜ直接コミットしないのかは前述のとおり、コミットに含める変更を選ぶためだ。git diff --staged でステージ済みの内容を最終確認できる。

5. commit — スナップショットを撮る

git commit -m "feat: add greeting script"

メッセージには「何をしたか」を1行で書く。未来の自分と同僚が git log を読んだとき、コードを開かずに変更の意図が分かることが目的だ。確認: git log --oneline -3 の先頭に自分のコミットが積まれている。

6. push — 並行世界をリモートへ送る

git push -u origin feature/add-greeting

ローカルのコミットは、pushするまで世界のどこにも共有されていない。-u は「このローカルブランチはリモートの同名ブランチと対応する」という紐付けで、初回だけ必要。以後は git push だけでよい。確認: GitHubのリポジトリページにブランチ名が表示される。

7. Pull Request — レビューと合流の依頼

GitHub上で「このブランチをmainに取り込んでください」と依頼するのがPull Request（PR）だ。変更の差分が一覧され、レビュアーがコメントを付け、議論の記録が残る。チーム開発のコード品質は、ほぼこの場で担保される。pushするとGitHubに「Compare & pull request」ボタンが現れるので、変更の目的と内容を書いて作成する。

8. merge — 歴史が合流する

レビュー通過後、PR画面のMergeボタンで分岐した歴史がmainに合流する。合流後は、自分のローカルのmainを追いつかせておく。

git switch main
git pull    # bring the merged history into local main
git branch -d feature/add-greeting    # delete the finished branch

最初につまずく3つのポイント

コンフリクトとの初遭遇

複数の人が同じファイルの同じ箇所を別々に変更すると、Gitはどちらを正とすべきか機械的に判断できず、人間に委ねてくる。これがコンフリクト（競合）だ。何かが壊れたわけではない。ファイルを開くと目印が挿入されている。

<<<<<<< HEAD
    return f"Hello, {name}!"
=======
    return f"Hi, {name}."
>>>>>>> main

<<<<<<< から ======= までが自分の変更、そこから >>>>>>> までが相手の変更。あるべき最終形になるよう手で書き直し（目印の3行は削除する）、git add して git commit すれば解決だ。どちらを残すべきか迷ったら、相手の変更をした本人に聞くのが一番早い。

push rejected

git push が ! [rejected] で失敗することがある。自分がpushしようとした先に、他人のコミットが先に積まれていた、という意味だ。リモートの新しい歴史を知らないままpushを許すと、そのコミットを置き去りにしてしまうため、Gitが拒否している。git pull でリモートの変更を取り込んでから、あらためてpushすればよい。

add忘れ

「コミットしたはずの変更が入っていない」——原因の大半は git add のし忘れで、変更が作業ツリーに残ったままになっている。git commit の前に git status を見て、対象ファイルが「Changes to be committed」に入っているか確かめる癖をつければ防げる。

まとめと次の一歩

流れは1本道だ: clone → switch -c → 編集 → add → commit → push → Pull Request → merge → pull。そして各コマンドの背後には「スナップショットの鎖」「動くラベル」「ローカルとリモートの同期」というモデルがある。コマンドを忘れてもモデルを覚えていれば調べ直せるが、逆は難しい。

次の一歩は3つ。(1) 自分用のリポジトリを作り、上の流れを最低3周すること。(2) git log と git diff を日常的に読むこと。(3) 無料公開されている公式書籍『Pro Git』の1〜3章を読むこと。ここまでやれば、Gitは「怖い呪文」から「歴史を扱う道具」に変わる。