Gitブランチ戦略も参考にしてください。
関連記事：Web開発技術マップ2026｜フロントエンド・バックエンド・インフラの全体像もあわせてご覧ください。
プログラミングを学んでいると「Git」と「GitHub」という言葉を頻繁に目にします。Gitはコードの変更履歴を管理するツール、GitHubはその履歴をチームで共有するためのプラットフォームです。どちらもエンジニアとして働くうえで避けて通れないスキルです。
この記事では、GitとGitHubの基本概念から実際の操作方法、チーム開発での使い方まで解説します。
Gitとは何か
Gitの概要
Gitは、分散型バージョン管理システムです。ファイルの変更履歴を記録し、過去の状態に戻したり、複数人の変更を統合したりする機能を提供します。
Linus Torvalds氏（Linuxの作者）が2005年に開発しました。現在ではソフトウェア開発のバージョン管理のデファクトスタンダードとなっています。
バージョン管理がなぜ必要か
バージョン管理がない状態だと、以下のような問題が起きます。
- ファイル名に日付を付けて管理する（
index_20260401.html） - 誰がいつどんな変更をしたか追跡できない
- 複数人が同じファイルを編集した際に変更が上書きされる
- 動いていた状態に戻せなくなる
Gitはこれらの問題を解決し、誰が・いつ・何を・なぜ変更したかを正確に記録します。
GitとGitHubの違い
両者の比較
初心者が混乱しやすいポイントですが、GitとGitHubは別のものです。
| Git | GitHub | |
|---|---|---|
| 種類 | バージョン管理ツール | Webサービス |
| 動作環境 | ローカルPC | クラウド（Web） |
| 主な機能 | 変更履歴の記録 | リモートリポジトリのホスティング、コラボレーション |
| 料金 | 無料（オープンソース） | 無料プランあり（有料プランもあり） |
類似サービスの存在
Gitはローカルで動作するツールで、GitHubはGitのリポジトリをクラウド上で共有・管理するサービスです。GitHubの他にもGitLab、Bitbucketなど同様のサービスがあります。
Gitのインストールと初期設定
インストール
- Windows：Git公式サイトからインストーラーをダウンロードして実行
- macOS：
xcode-select --installまたはHomebrewでbrew install git - Linux：
sudo apt install git（Ubuntu/Debian）またはsudo dnf install git（Fedora）
# バージョン確認
git --version
初期設定
# ユーザー名とメールアドレスを設定（コミット履歴に記録される）
git config --global user.name "あなたの名前"
git config --global user.email "your-email@example.com"
# デフォルトブランチ名をmainに設定
git config --global init.defaultBranch main
Gitの基本操作
リポジトリの作成
mkdir my-project
cd my-project
git init
git initで現在のディレクトリをGitリポジトリとして初期化します。
ターミナル入門も参考にしてください。
基本的なワークフロー
Gitの基本的な流れは以下の3ステップです。
- ファイルを編集する
- ステージングエリアに追加する（
git add） - 変更を記録する（コミット）（
git commit）
# ファイルの変更状態を確認
git status
# 変更をステージングエリアに追加
git add index.html # 特定のファイル
git add . # すべての変更
# 変更を記録（コミット）
git commit -m "トップページのレイアウトを修正"
# 変更履歴を確認
git log --oneline
ステージングエリアの役割
Gitでは、変更したファイルがすぐにコミットされるわけではありません。git addでステージングエリアに追加したファイルだけがコミットの対象になります。この仕組みにより、「今回のコミットに含める変更」を選択できます。
作業ディレクトリ → [git add] → ステージングエリア → [git commit] → リポジトリ
ブランチの使い方
ブランチは、コードの変更を本線（メインブランチ）から分離して作業するための機能です。
ブランチの基本操作
# ブランチの一覧を確認
git branch
# 新しいブランチを作成して切り替え
git checkout -b feature/add-login
# ブランチの切り替え
git checkout main
# ブランチの削除
git branch -d feature/add-login
ブランチを使う理由
- メインブランチを安定した状態に保てる：開発中のコードが本番に影響しない
- 機能ごとに作業を分離できる：複数の機能を並行して開発できる
- 変更のレビューが容易：プルリクエストでコードレビューできる
マージ（統合）
ブランチでの作業が完了したら、メインブランチに統合します。
GitHub Actions実践ガイドも参考にしてください。
# メインブランチに切り替え
git checkout main
# ブランチをマージ
git merge feature/add-login
GitHubの使い方
GitHubアカウントの作成
GitHub公式サイトでアカウントを作成します。無料プランで個人開発には十分な機能が利用できます。
リモートリポジトリとの連携
# リモートリポジトリを追加
git remote add origin https://github.com/username/my-project.git
# ローカルの変更をリモートに送信（プッシュ）
git push -u origin main
# リモートの変更をローカルに取得（プル）
git pull origin main
プルリクエスト（Pull Request）
プルリクエスト（PR）は、ブランチの変更をメインブランチに統合する前にチームメンバーにレビューを依頼する仕組みです。
プルリクエストの一般的な流れは以下のとおりです。
- ブランチを作成して作業する
- 変更をリモートにプッシュする
- GitHub上でプルリクエストを作成する
- チームメンバーがコードをレビューする
- 問題なければマージする
Issues（イシュー）
GitHubのIssuesは、バグ報告、機能要望、タスク管理に使われます。プルリクエストとIssueを紐づけることで、どの変更がどの課題に対応しているか追跡できます。
コンフリクト（衝突）の解消
複数人が同じファイルの同じ箇所を編集した場合、マージ時にコンフリクトが発生します。
<<<<<<< HEAD
<h1>現在のブランチの内容</h1>
=======
<h1>マージしようとしているブランチの内容</h1>
>>>>>>> feature/update-header
コンフリクトが発生したら、該当箇所を手動で修正し、マーカー（<<<<<<<、=======、>>>>>>>）を削除してからコミットします。
# コンフリクトを解消した後
git add .
git commit -m "コンフリクトを解消"
技術メモ：.gitignoreの設定と便利なコマンド
Gitリポジトリに含めるべきでないファイル（パスワード、ビルド成果物、OS固有のファイルなど）を管理するために、.gitignoreファイルを作成します。
実際に手を動かしてみましょう。プロジェクトルートに以下のような.gitignoreを作成します。
# 依存パッケージ
node_modules/
# 環境変数
.env
.env.local
# ビルド成果物
dist/
build/
# OS固有ファイル
.DS_Store
Thumbs.db
# エディタ設定
.vscode/
.idea/
gitignore.io（https://www.toptal.com/developers/gitignore）では、言語やフレームワークに応じた`.gitignore`のテンプレートを生成できます。
また、以下のコマンドは日常的に使う場面が多いため、覚えておくと便利です。
# 直前のコミットメッセージを修正（プッシュ前のみ推奨）
git commit --amend -m "修正後のメッセージ"
# 特定のファイルの変更履歴を確認
git log --oneline -- ファイル名
# ステージングを取り消す（ファイルの変更は残る）
git restore --staged ファイル名
Git/GitHub学習のロードマップ
ステップ1：Gitの基本操作を覚える（目安：3〜5日）
init、add、commit、status、logの5つのコマンドを使いこなせるようになりましょう。自分のプロジェクトで実際に使いながら覚えるのが効果的です。
ステップ2：ブランチ操作を学ぶ（目安：3〜5日）
ブランチの作成、切り替え、マージ、削除を学びます。コンフリクトの解消も練習しておきましょう。
ステップ3：GitHubとの連携を学ぶ（目安：1週間）
リモートリポジトリへのプッシュ・プル、プルリクエストの作成、コードレビューの流れを学びます。
ステップ4：チーム開発のワークフローを理解する（目安：1週間）
Git Flowやトランクベース開発など、チーム開発でのブランチ戦略を学びます。実際のプロジェクトで使われるワークフローを知っておくと実務に役立ちます。
ステップ5：GitHubの便利機能を活用する
Issues、Projects、Actions（CI/CD）などの機能を学び、開発プロセス全体の効率化に活用しましょう。
よくある質問（FAQ）
Q. GUIツールとコマンドラインのどちらを使うべきですか？
A. 最初はコマンドラインで基本操作を覚えることをおすすめします。Gitの仕組みを理解するにはコマンドラインが適しています。基本を理解したうえで、VS Codeの統合Git機能やSourcetreeなどのGUIツールを併用すると効率的です。
Q. コミットメッセージの書き方に決まりはありますか？
A. 一般的に「何を変更したか」が一目でわかる簡潔なメッセージが推奨されます。チームによって規約は異なりますが、「動詞で始める」「日本語 or 英語を統一する」「Issue番号を含める」などのルールがよく使われます。
Q. 間違えてコミットした場合はどうすればいいですか？
A. 直前のコミットを修正する場合はgit commit --amendが使えます。ただし、リモートにプッシュ済みのコミットを修正する場合は注意が必要で、チームへの影響を考慮する必要があります。
Q. GitHubのプロフィールは就職活動に影響しますか？
A. 技術系企業ではGitHubのアカウントを参考にするケースがあります。コードの品質、コミット頻度、READMEの整備状況などが見られることがあるため、学習用リポジトリでも丁寧に管理しておくとプラスに働く可能性があります。
Q. SSHとHTTPSのどちらで接続すべきですか？
A. どちらでも利用可能です。HTTPSはセットアップが簡単ですが、プッシュのたびに認証が必要です（認証情報のキャッシュ設定で軽減可能）。SSHは初回の鍵設定が必要ですが、設定後はパスワード入力なしで操作できます。長期的にはSSH接続が便利です。
まとめ
GitとGitHubは、エンジニアとして働くうえで欠かせないツールです。Gitでコードの変更履歴を管理し、GitHubでチームとの共同作業を効率化できます。
学習は「まず自分のプロジェクトでGitの基本コマンドを使う」ところから始めましょう。add、commit、pushの3つの操作に慣れたら、ブランチやプルリクエストの使い方に進めるのがおすすめです。日常的に使い続けることで自然と身につきます。