GitとGitHubの使い方｜チーム開発の基本：現場で「やらかさない」ための完全ガイド

Webエンジニアとして15年ほど現場に立ち続けている者です。現在はフリーランスとして企業の開発支援をしつつ、副業でプログラミングスクールのメンターとして、これまで数百人の初心者のコードを見てきました。

いきなりですが、正直に告白します。
私がエンジニア人生で一番冷や汗をかいた瞬間は、サーバーをダウンさせた時でも、本番環境でバグを出した時でもありません。

新人の頃、チームの先輩が1週間かけて書いた大事なプログラムのファイルを、誤って「古いバージョン」で上書きして消し飛ばしてしまった瞬間です。

あの時の、血の気が引いて指先が冷たくなる感覚。チャットツールで「あれ？ 最新のコードどこいった？」と先輩からメッセージが来た時の、心臓がキュッと縮む音。今でも鮮明に覚えています。
当時の現場は、まだGitのようなバージョン管理システムが今ほど当たり前ではなく、共有サーバー上のファイルを直接編集したり、FTPでアップロードしたりという、今思えば狂気のような運用をしていました。「最新版」という名前のフォルダがいくつも並び、どれが本当の最新なのか誰にも分からない。そんなカオスの中で、私は取り返しのつかないミスを犯したのです。

「Git（ギット）って難しそう」
「黒い画面（ターミナル）でコマンド打つの怖い」
「addとかcommitとか、呪文にしか見えない」

もしあなたがそう感じているなら、すごく分かります。私も最初はそうでした。専門用語は多いし、英語だし、失敗したら画面が真っ赤になるし。
でも、断言します。プログラミング言語の文法を覚えるよりも、Gitを覚える方が、あなたのエンジニアとしての寿命を確実に延ばします。

なぜなら、プログラミング言語は「何を作るか」のための道具ですが、Gitは「チームでどう働くか」という信頼の基盤そのものだからです。コードが書けてもGitが使えないエンジニアは、現場では「爆弾を抱えた人」として扱われてしまいます。

この記事では、単なるコマンドの辞書的な解説書ではなく、「現場ではどういう思考でGitを使っているのか」「なぜチーム開発でこれがないと死ぬのか」という、泥臭い実体験に基づいた話をします。教科書には載っていない、現場のリアルな運用ルールや、初心者が必ず踏む地雷ポイントも余すところなくお伝えします。

これを読み終える頃には、GitHubのプルリクエストボタンを押す手が、震えなくなっているはずです。そして、チーム開発というものの本当の楽しさを知る準備が整っているでしょう。

なぜチーム開発にGitが「絶対」必要なのか？

現場に入ると、Gitを使わない日はありません。朝起きて顔を洗うように、PCを開いたら git pull を叩きます。
なぜそこまで重要なのでしょうか。それは、Gitが単なる「バックアップツール」ではなく、「タイムマシン」であり「並行世界の管理ツール」だからです。

「ファイル名で管理」の地獄絵図

Gitを使わない世界線を想像してみてください。
例えば、あなたが副業で友人3人とWebサービスを作るとします。Aさんはトップページのデザインを修正、Bさんは決済機能を実装、あなたはログイン画面を作っています。

ファイルを共有フォルダ（DropboxやGoogle Driveなど）に入れて作業していると、フォルダの中身はすぐにこうなります。

• index.html
• index_new.html
• index_fixed.html
• index_final.html
• index_final_hontoni_final_v2.html
• index_20241123_tanaka.html

笑い話のようですが、Gitがない現場ではこれが現実です。
「どれが最新だっけ？」
「Aさんの修正とBさんの修正、どっちをベースにすればいいの？」
「やばい、間違えて昨日のファイルで上書きしちゃった！」

そしてある日、あなたが「最新だと思って」編集した index_final.html が、実はBさんが昨日徹夜で修正した内容を含んでいなかったとしたら？
あなたが保存ボタンを押した瞬間、Bさんの昨日の仕事はデジタル空間から消滅します。これが「先祖返り」と呼ばれる現象です。この瞬間、チームの空気は凍りつき、人間関係に修復不可能な亀裂が入ります。

Gitがあれば、ファイル名は常に index.html ひとつだけ。
「誰が、いつ、何を変えたか」が全て歴史として残り、いつでも1分前の状態にも、1年前の状態にも戻せます。これが「タイムマシン」の機能です。

並行世界（ブランチ）を作る魔法

そしてもう一つ、チーム開発で最強の機能が「ブランチ（Branch）」です。
これは、メインの世界（本番用コード）から、自分専用の「並行世界」を枝分かれさせて作業できる機能です。

• Mainブランチ: 常に正しく動く世界。ここには完成品しか置かない。
• Aさんの世界（ブランチ）: デザイン修正中。まだぐちゃぐちゃでもOK。
• Bさんの世界（ブランチ）: 決済機能開発中。バグだらけでもOK。

自分の世界（ブランチ）でどれだけ破壊的な変更をしても、メインの世界や他の人の世界には一切影響しません。
間違えてコードを全消去しても、それはあくまで「自分の並行世界」での出来事。メインの世界は無傷です。

そして作業が終わって、完全に動くことが確認できてから、メインの世界に合流（マージ）させる。
この仕組みがあるから、私たちは安心してコードを書き換えることができるんです。失敗を恐れずにトライアンドエラーができる。これがGitを使う最大のメリットです。

まずはここから：環境構築と初期設定の「落とし穴」

具体的なコマンドの話に入る前に、環境設定の話をさせてください。
スクールの教材通りにインストールしたけれど、現場に出てから「設定がおかしいよ」と指摘される初心者が後を絶ちません。最初のボタンの掛け違いは、後で大きなズレになります。

1. ユーザー名とメールアドレスの設定

Gitは「誰が変更したか」を記録するツールです。ここが設定されていないと、チームメンバーから「名無しの権兵衛がコードをいじっている」と不審がられます。

ターミナル（WindowsならGit Bash、Macならターミナル）を開いて、以下のコマンドを確認してください。

# 設定されているか確認
git config --global user.name
git config --global user.email

何も出ない、または身に覚えのない名前（PCの初期設定名など）になっていたら、今すぐ設定しましょう。

git config --global user.name "Taro Yamada"
git config --global user.email "taro.yamada@example.com"

【超重要ポイント】
ここで設定するメールアドレスは、GitHubに登録するものと同じにしてください。
ここがズレていると、GitHub上であなたのアイコンが表示されず、あの緑色の「草（Contributes）」も生えません。
就職活動や副業のポートフォリオとしてGitHubを見せる時、「あれ？ この人全然活動してないな（コミット数が0に見える）」と誤解される原因になります。
技術力以前の問題で損をするのはあまりにも勿体無いです。必ず確認してください。

2. 改行コードの自動変換設定（autocrlf）

WindowsとMacが混在するチームでは、改行コードの違い（WindowsはCRLF、Mac/LinuxはLF）が原因でトラブルが起きます。
何も変更していないのに、Gitが「全行変更された！」と誤検知してしまうのです。

Windowsユーザーは以下の設定をしておくと、コミット時に自動でLFに変換してくれます。

git config --global core.autocrlf true

Macユーザーは input に設定します。

git config --global core.autocrlf input

3. デフォルトブランチ名の設定

以前はメインのブランチ名は master がデフォルトでしたが、現在は人種差別的な用語を避ける観点から main を使うのが世界標準です。
古いGitを使っていると勝手に master が作られてしまうので、初期設定を変えておきましょう。

git config --global init.defaultBranch main

こういう「環境の差異」を吸収する設定を最初にしておくのが、プロの嗜みです。

Gitの基本概念：3つのエリアを理解する

Gitを難しく感じさせる原因は、「今、自分のファイルがどこにあるのか」が直感的に分からないからです。
よくある解説図では「ワークツリー」「インデックス」「リポジトリ」なんて専門用語が出てきて眠くなりますが、私はいつもこう例えています。

この3段階をイメージしてください。

1. 作業机（ワークツリー）:
   あなたが今、エディタ（VS Codeなど）で開いてコードを書いている場所。散らかっていても、書きかけでもOK。
2. 撮影ステージ（インデックス／ステージング）:
   記念撮影をするために、必要なものだけを選んで並べる場所。「この変更は記録に残すぞ」と選別する工程（git add）。
3. アルバム（リポジトリ）:
   撮影した写真を保存する場所。一度アルバムに貼ったら、基本的には消えない歴史になります（git commit）。

初心者がよくやるミスは、作業机からいきなりアルバムに貼ろうとすることです。
Gitでは必ず、「作業机」→「撮影ステージ」→「アルバム」という手順を踏みます。面倒に感じるかもしれませんが、これには理由があります。
「パスワードが書かれたファイルだけはアルバムに入れたくない」といった場合に、ステージングという「選別場所」があることで事故を防げるのです。

基本のコマンドフロー

実際に手を動かす時の流れはこうなります。

1. 変更をステージに乗せる（git add）

# 特定のファイルだけ乗せる場合
git add index.html

# 変更した全ファイルを乗せる場合（現場ではこっちが多い）
git add .

git add . は「今ある変更全部！」という豪快なコマンドです。便利ですが、ゴミファイル（自動生成された不要なファイルなど）までステージに乗せてしまう危険があります。これについては後述する .gitignore で防ぎます。

2. 状態を確認する（git status）

私が開発中に一番多く叩くコマンドです。1時間に10回は叩きます。迷ったらとりあえずこれを打ちます。

git status

これを打つと、「今ステージに乗っているファイル（緑色）」と「まだ乗っていないファイル（赤色）」が分かります。
信号機みたいなものです。全部緑色になっていれば、撮影（コミット）準備完了です。赤色が残っていたら、まだ add されていません。

3. 記録する（git commit）

ステージに乗った変更を、歴史として保存します。

git commit -m "ログイン機能のレイアウトを作成"

ここで最も重要なのが -m の後ろのメッセージです。
「修正」「更新」「update」みたいなメッセージは大罪だと思ってください。
半年後の自分、あるいはチームメンバーが見た時に、「なぜこの変更をしたのか」が分からないと、バグ調査の時に詰みます。

【良いコミットメッセージの例】

• お問い合わせフォームのバリデーションを追加
• ヘッダーの背景色を青から白に変更（視認性向上のため）
• バグ修正：スマホ表示時にメニューが崩れる問題を解消

【悪い例】

• あ （テストでもやめましょう）
• fix （何をしたの？）
• wip （Work In Progressの略。一時保存なら許されますが、そのままマージされると困ります）

現場のスタンダード：GitHub Flow（ギットハブ・フロー）

さて、ここからが本題です。
一人で開発しているうちは add と commit だけでもなんとかなりますが、チーム開発ではそうはいきません。
現在、多くのWeb系企業やスタートアップで採用されているのが「GitHub Flow」という開発スタイルです。シンプルで高速に開発を回すためのルールです。

現場に入ると、このサイクルを1日に何度も、息をするように回すことになります。
流れを一つずつ、丁寧に見ていきましょう。

Step 1. 最新の状態を取得する（git pull）

作業を始める前、朝一番にやる儀式。「他のメンバーが進めた分」を自分の手元に取り込みます。
これを忘れて作業を始めると、後で「コンフリクト（衝突）」の地獄を見ます。

# mainブランチに移動
git switch main

# リモート（GitHub）の最新情報をローカルに取り込む
git pull origin main

Tips: 最近のGit（2.23以降）では、ブランチの切り替えに git checkout ではなく git switch を使うのが推奨されています。checkout は「過去に戻る」「ファイルを戻す」「ブランチを変える」など機能が多すぎて混乱の元だったためです。switch の方が直感的でおすすめです。

Step 2. 作業用のブランチを切る（git switch -c）

絶対に、絶対にやってはいけないこと。それはmainブランチで直接作業することです。
main は神聖な場所です。常に本番環境にデプロイできる綺麗な状態を保たなければなりません。

必ず、作業用の分身を作ります。

# feature/login-design という名前のブランチを作成して、同時に移動
git switch -c feature/login-design

ブランチ名の付け方はチームによりますが、一般的には以下のようなプレフィックス（接頭辞）をつけます。

• feature/xxx: 新機能の開発（例：feature/add-user-page）
• fix/xxx: バグ修正（例：fix/login-error）
• docs/xxx: ドキュメント修正（例：docs/update-readme）

ローマ字で kinou_tsuika と書くと、現場では「おっ、新人くんかな？」と生温かい目で見られます。頑張って英語を使いましょう。

Step 3. 作業してプッシュする（git push）

コードを書き、add して commit します。ここまではローカル（自分のPC）だけの話です。
これをGitHub（リモート）に送ります。

git push origin feature/login-design

これを実行すると、GitHub上にあなたの作業用ブランチが出来上がります。まだ main には合流していません。

Step 4. プルリクエスト（PR）を作成する

ここがチーム開発のハイライトです。
GitHubの画面を開くと、「Compare & pull request」という緑色のボタンが出現しているはずです。

これをクリックして、「プルリクエスト（通称：PR）」を作成します。
プルリクエストとは、「私の変更を main に取り込んでください（Pullしてください）！」という依頼書です。

ここに何を書くかが、エンジニアの評価を大きく分けます。
黙ってコードだけ置いて「見れば分かるだろ」というスタンスのエンジニアは、どれだけ技術力があっても現場では歓迎されません。

【PRに書くべき必須項目】

• 概要: 何を作ったのか、何を直したのか。
• 目的・背景: なぜその変更が必要だったのか。
• 確認手順: レビュアー（確認する人）はどうやって動作確認すればいいか。
• スクリーンショット: 画面の変更があるなら必須！

特にスクリーンショット（スクショ）は死ぬほど大事です。コードの羅列を見てデザインの崩れを想像するのは、ベテランでも不可能です。「百聞は一見に如かず」です。Before/Afterの画像があるだけで、レビュー速度が3倍になります。動画（GIF）ならもっと最高です。

Step 5. コードレビューとマージ

PRを出すと、チームメンバーからレビュー（指摘）が入ります。

「ここの変数名、もっと分かりやすくできる？」
「このロジックだと、データが空の時にエラーになるよ」
「インデントがずれてるよ」

これを「攻撃された」「ダメ出しされた」と受け取って凹む必要はありません。コードレビューは、みんなでコードを磨き上げ、バグを防ぐための協力プレイです。
指摘されたら、ローカルで修正して、再度 add, commit, push します。するとPRの内容も自動で更新されます。わざわざPRを作り直す必要はありません。

レビューで「LGTM（Looks Good To Me：これでOKだよ）」をもらったら、いよいよ「Merge」ボタンを押します。
これであなたのコードが正式にプロジェクトの一部になります。この瞬間が、エンジニアとして一番達成感を感じる時かもしれません。

恐怖！コンフリクト（競合）への対処法

チーム開発をしていると、避けて通れないのが「コンフリクト（Conflict）」です。
同じファイルの同じ行を、自分と他の人が同時に修正してしまった時に発生します。

Gitは悩みます。「Aさんは『色は赤』って言ってるけど、Bさんは『色は青』って言ってる…。どっちを採用すればいいの？ 私には決められないよ！」

これがコンフリクトです。ターミナルに CONFLICT という不吉な文字が表示され、自動マージが停止します。
初心者の頃はこれでパニックになり、「もうダメだ、全部消してやり直したい」と思うかもしれません。でも、落ち着いてください。解決方法はシンプルです。

1. コンフリクトしているファイルを開く

VS Codeなどのエディタで、該当するファイルを開いてみてください。Gitが親切（？）に、どこが喧嘩しているかマークを付けてくれています。

<<<<<<< HEAD
<button class="red-btn">ログイン</button>
=======
<button class="blue-btn">ログイン</button>
>>>>>>> feature/other-branch

• <<<<<<< HEAD から ======= までが、自分（今いるブランチ）のコード。
• ======= から >>>>>>> までが、相手（取り込もうとしているブランチ）のコードです。

2. 人間の手で修正する

ここはAIでもGitでもなく、人間が判断する必要があります。
「今回はBさんの青を採用しよう」とか「いや、両方の変更を取り入れよう」と決めて、不要な記号（<<<<<<< など）を全て消し、正しいコードだけを残します。

<!-- 話し合いの結果、青にすることにした -->
<button class="blue-btn">ログイン</button>

3. 再度コミットする

修正が終わったら、いつも通りです。

git add .
git commit -m "コンフリクトを解消"

これで解決です。
コンフリクトは「事故」ではなく「対話のきっかけ」です。「ここ被っちゃったね、どうする？」とチームで相談する良い機会だと捉えましょう。Slackで「コンフリクトしたので相談させてください！」と言える勇気が大事です。

現場で「できる」と思われるGitの習慣

ここまで基本的な流れを解説しましたが、最後に「こいつ、できるな」と思われるための、ちょっとした、でも重要な習慣を紹介します。

1. コミットの粒度は細かく（アトミック・コミット）

初心者がやりがちなのが、3日分の作業をまとめて1回でコミットすること。これは「巨大なコミット」と呼ばれ、レビューする側にとっての悪夢です。
30個のファイルを同時に変更されたら、どこにバグが潜んでいるか見つけるのは至難の業だからです。

理想は「1つの作業につき1コミット」です。
「レイアウト修正」と「ロジック修正」は分けましょう。
こうすることで、後から「レイアウトだけ元に戻したい」と思った時に、git revert で簡単に戻せるようになります。

2. .gitignore を正しく使う

Gitで管理すべきでないファイルがあります。

• OSの自動生成ファイル（Macの.DS_Storeなど）
• パスワードやAPIキーが書かれた設定ファイル（.envなど）
• ビルドされた成果物やライブラリ（node_modulesなど）

これらを誤ってGitHubにアップロードしてしまうと、セキュリティ事故に繋がります。
特にAWSのアクセスキーなどを公開してしまい、一晩で数百万円の請求が来たなんて怖い話も実際にあります。都市伝説ではありません。
プロジェクトの最初には必ず .gitignore ファイルを作成し、不要なファイルを除外する設定を行いましょう。GitHubが用意しているテンプレートを使うのが無難です。

3. 迷ったら git status

しつこいようですが、何が起きたか分からなくなったら、まずは深呼吸をして git status です。
今自分がどのブランチにいて、どのファイルが変更されているのか。現状把握なしに行動すると、傷口を広げます。
「なんかおかしいな？」と思ったら、適当にコマンドを叩く前に、まず現状を確認する。これがトラブルシューティングの鉄則です。

よくある質問（FAQ）

メンターとして活動している中で、頻繁に聞かれる質問に答えます。

Q. コマンド（CUI）とアプリ（GUI）、どっちがいいの？

A. 最初はコマンド（CUI）を強くおすすめします。
SourceTreeやGitKrakenのような便利なGUIツールも素晴らしいですが、裏で何が起きているか理解しないまま使うと、トラブルが起きた時に手も足も出なくなります。「黒い画面」へのアレルギーを今のうちに克服しておくと、エンジニアとしての基礎体力がつきます。
仕組みを理解した後なら、GUIを使っても構いません。私も複雑なコミットログを見る時はGUIを使います。適材適所です。

Q. 誤って変なコミットをしちゃいました。戻せますか？

A. 戻せます。Gitはタイムマシンですから。
git reset というコマンドを使えば、過去の状態に戻せます。

# 直前のコミットを取り消して、変更内容は手元に残す（ソフトリセット）
git reset --soft HEAD^

ただし、git reset --hard は強力すぎて作業中の内容まで消し飛ばす諸刃の剣なので、使う時は慎重に。「Git 戻し方」で検索すれば対処法はたくさん出てきます。諦めないでください。

Q. GitHubのアカウント名は本名が良いですか？

A. 就職活動や副業を考えているなら、ある程度認識しやすいものが無難です。
完全な本名である必要はありませんが、あまりにふざけた名前や意味不明な文字列よりは、ポートフォリオとして見せた時に恥ずかしくない名前が良いでしょう。
また、アイコンも初期設定のままではなく、何かしら画像を設定しておくと「人間味」が出てコミュニケーションが円滑になります。これ、意外と大事ですよ。

副業・フリーランスを目指す人へのメッセージ

最後に、キャリアの話を少しだけさせてください。
「プログラミングスクールを卒業したら副業で稼ぎたい」「フリーランスになりたい」という人は多いですが、実際の案件獲得の現場では、ポートフォリオとしてGitHubのURLを求められることが非常に多いです。

クライアントや、間に立つCTOクラスのエンジニアは、あなたのGitHubの何を見ているのでしょうか？
綺麗なコードが書けるかどうか？ もちろんそれも見ます。
ですが、それ以上に「チームで仕事ができる人か？」を見ています。

• コミットメッセージは丁寧か？（他者への配慮があるか）
• プルリクエストの説明は分かりやすいか？（報告・連絡・相談ができるか）
• ブランチの切り方は適切か？（ルールを守れるか）

コードそのものの品質と同じくらい、Gitの使い方にあなたの仕事のスタンス（姿勢）が現れます。
Gitを丁寧に扱える人は、仕事も丁寧です。逆に、コミットログが汚い人は、仕事も雑だろうと判断されてしまいます。

たかがツール、されどツール。
Gitは、エンジニアとしてのあなたの信頼を担保する「履歴書」であり「証明書」のようなものです。

最初は面倒くさいと感じるかもしれません。「いちいちコマンド打つのだるいな」と思うでしょう。
でも、そのひと手間が、未来のあなたとチームメンバーを救います。

失敗しても大丈夫。ローカルの失敗なら、フォルダごと消して clone し直せばいいだけです（笑）。
恐れずに、まずは今日の学習コードを git init することから始めてみてください。その小さな一歩が、未来の現場での大きな信頼に繋がります。あなたのエンジニアライフが、Gitによってより自由で安全なものになることを応援しています。