この記事は約6分で読めます。
筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ
Git と GitHub の違い、説明できますか？ 新卒の頃、私は「プルリクエスト出しておいて」と言われて意味が分かりませんでした。この記事では、Git の基本からブランチ運用、GitHub Actions による CI/CD 自動化まで、実際の個人開発で使っている構成を添えて全体像をお見せします。
この記事の対象読者
- Git / GitHub を使い始めたが、全体像がつかめていない方
-
git addgit commitは打てるが、なぜそうするのか分かっていない方 - GitHub Actions や CI/CD という言葉を聞いたことはあるが、触ったことがない方
Git・GitHub・GitHub Actions の関係を整理する
まず、よく混同される 3 つの概念を整理します。
| 概念 | 何か | 公式サイト |
|---|---|---|
| Git | バージョン管理システム（ソフトウェア） | git-scm.com |
| GitHub | Git リポジトリのホスティングサービス | github.com |
| GitHub Actions | GitHub に組み込まれた CI/CD 自動化機能 | GitHub Actions ドキュメント |
一言でまとめると:
Git = ローカルPC上のバージョン管理ツール
GitHub = Git のデータをクラウドに保存・共有するサービス
GitHub Actions = GitHub 上で自動処理を実行する仕組み
Git がなければ GitHub は使えません。 GitHub は Git の上に乗っかっているサービスです。
Part 1: Git の基本 — 「なぜバージョン管理が必要なのか」
Git はファイルの変更履歴を自動で記録し、いつでも過去の状態に戻せるツールです。
Git の 3 つのエリア — ここが最初のつまずきポイント
Git を理解する最初のステップは、3 つのエリアを知ることです。
[ワーキングディレクトリ] → [ステージングエリア] → [ローカルリポジトリ]
作業場所 git add git commit
ファイルを編集 変更を選択 変更を記録
| エリア | 役割 | コマンド |
|---|---|---|
| ワーキングディレクトリ | 実際にファイルを編集する場所 | — |
| ステージングエリア | 「次のコミットに含める変更」を選ぶ場所 | git add |
| ローカルリポジトリ | 変更履歴が記録される場所 | git commit |
「なぜ git add と git commit を分けるのか？」 と疑問に思いませんか？
答えは、変更の一部だけをコミットしたい場合があるからです。例えば、バグ修正と新機能追加を同時に作業した場合、バグ修正だけを先にコミットしたい。git add で「このファイルだけ」と選べるのが、ステージングエリアの存在理由です。
よく使う Git コマンド 7 選
| コマンド | 意味 | 使う場面 |
|---|---|---|
git init |
リポジトリを新規作成 | プロジェクト開始時 |
git clone <URL> |
リモートリポジトリをコピー | 既存プロジェクトに参加時 |
git status |
変更状態を確認 | 迷ったらまずこれ |
git add <file> |
変更をステージング | コミット前 |
git commit -m "メッセージ" |
変更を記録 | 区切りの良いタイミングで |
git log --oneline |
履歴を確認 | 過去のコミットを探す時 |
git diff |
変更内容を確認 | コミット前の最終確認 |
Part 2: ブランチ — 「なぜ main を直接触ってはいけないのか」
ブランチは「並行世界」
ブランチは 「並行世界」 です。main ブランチ（本番）に影響を与えずに、別の世界線で作業できます。
main: A --- B --- C --- D（本番）
\
feature: E --- F --- G（開発中の新機能）
feature ブランチで失敗しても、main は無傷です。新機能が完成してからマージ（合流） すれば、本番に反映されます。
ブランチ運用の基本フロー
# 1. 新しいブランチを作成して切り替え
git checkout -b feature/add-login
# 2. 作業してコミット
git add .
git commit -m "ログイン機能を追加"
# 3. リモートにプッシュ
git push -u origin feature/add-login
# 4. GitHub 上でプルリクエストを作成
# → レビュー → マージ
「main を壊す」を防ぐ — ブランチ保護ルール
私が新卒の頃にやらかした「main を壊す」問題。これを防ぐには ブランチ保護ルール を設定します。
GitHub の Settings → Branches → Branch protection rules で:
- Require a pull request before merging — 直接 push を禁止
- Require approvals — レビューなしのマージを禁止
Part 3: GitHub の基本機能 — プルリクエストと Issues
プルリクエスト（PR）= 「このコード、見てください」
プルリクエストは 「自分のブランチの変更を main にマージしてほしい」というリクエスト です。
feature/add-login → main へのマージをリクエスト
↓
レビュワーがコードを確認
↓
LGTM（Looks Good To Me）→ マージ
PR がなぜ重要かというと、コードレビューの場 になるからです。自分では気づかないバグや設計の問題を、チームメンバーが指摘してくれます。
Issues で PR と連携する
Issues はタスク管理ツールです。バグ報告、機能要望、改善提案を Issue として登録し、PR で解決します。
Issue #42: ログインページのバグ修正
↓
PR #43: fix: ログインページのバリデーション修正 (closes #42)
↓
マージ → Issue #42 が自動的に閉じる
コミットメッセージや PR に closes #42 と書くと、マージ時に Issue が自動で閉じます。
Part 4: GitHub Actions — 「push したら自動で動く」CI/CD 入門
ここからが、Git / GitHub を「使える」から「活用できる」にレベルアップするパートです。
GitHub Actions とは
GitHub Actions は 「特定のイベントが起きたら、自動で処理を実行する」 仕組みです。
トリガー（いつ実行するか）
├── push → main にコードが push されたとき
├── pull_request → PR が作成されたとき
├── schedule → 毎日決まった時刻に（cron）
└── workflow_dispatch → 手動実行ボタン
ジョブ（何を実行するか）
├── テストを実行
├── ビルドを実行
├── デプロイを実行
└── 任意のスクリプトを実行
実例 ①: 個人ホームページの自動デプロイ
私が運用している個人ホームページでは、以下のワークフローが動いています。
# .github/workflows/deploy.yml
name: Deploy to GitHub Pages
on:
push:
branches: [main] # main に push されたら実行
schedule:
- cron: "0 21 * * *" # 毎日 JST 6:00 に実行（予約投稿用）
workflow_dispatch: # 手動実行も可能
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run build
- uses: actions/upload-pages-artifact@v3
with:
path: dist
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- uses: actions/deploy-pages@v4
このワークフローで何が起きるか:
結果: git push するだけでサイトが自動更新されます。
実例 ②: cron（定時実行）で予約投稿を実現
schedule:
- cron: "0 21 * * *" # 毎日 UTC 21:00 = JST 6:00
cron の書式は 分 時 日 月 曜日 です。GitHub Actions の cron は UTC 固定なので、JST との時差（-9時間）に注意してください。
| 式 | 意味 |
|---|---|
"0 21 * * *" |
毎日 UTC 21:00（= JST 6:00） |
"0 15 1 * *" |
毎月 1 日 UTC 15:00（= JST 0:00） |
"30 9 * * 1-5" |
平日 UTC 9:30（= JST 18:30） |
これを使って、ブログ記事の予約投稿 を実現しています。記事の date フィールドが「今日以前」になった日のビルドで、自動的に記事が公開されます。
実例 ③: PR 時の自動テスト + バージョン整合性チェック
個人開発アプリ「ユメハシ（YumeHashi、旧ユメログ）」では、PR を出した時点で自動テストとバージョン整合性チェックが走ります（※ アプリ自体は現在、新規ユーザー受付を停止中。本セクションは CI/CD 構成例として記載）。
# .github/workflows/test.yml（抜粋）
name: CI
on:
pull_request:
branches: [main] # main への PR が対象
jobs:
lint-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: subosito/flutter-action@v2
- run: flutter pub get
- run: flutter analyze # 静的解析（エラー0件でないと失敗）
- run: flutter test --coverage # 全テスト実行 + カバレッジ計測
version-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 全履歴が必要（main との比較のため）
- name: Check version update
run: |
MAIN_VERSION=$(git show origin/main:pubspec.yaml | grep '^version:')
PR_VERSION=$(grep '^version:' pubspec.yaml)
if [ "$MAIN_VERSION" = "$PR_VERSION" ]; then
echo "::error::バージョンが更新されていません"
exit 1
fi
ポイント:
-
flutter analyzeは warning も error 扱い（品質ゲート） -
version-checkでバージョン更新漏れを自動検知 → PR のマージを阻止 -
fetch-depth: 0で全履歴を取得し、main のバージョンと比較
「テストを通さずにマージしてしまう」「バージョン更新を忘れたままリリースする」事故を防止しています。
さらに応用として、週次ストレステスト + 閾値超過時の自動 Issue 起票や、デプロイ時のバージョンスタンプ自動書き換えなども GitHub Actions で実現できます。実際の構成は ユメハシのリポジトリ で確認できます。
まとめ — 全体像をもう一度
| あなたの状況 | 次にやること |
|---|---|
| Git を触ったことがない |
git init → git add → git commit を体験する |
| Git は使えるがブランチが怖い |
git checkout -b でブランチを切って PR を出してみる |
| GitHub は使えるが Actions を知らない | 上の deploy.yml をコピーして自分のリポジトリで動かしてみる |
Git は「バージョン管理ツール」ではなく、「チームの信頼を支えるインフラ」です。
実際の構成を見てみませんか？
この記事で紹介した構成は、私の個人開発プロジェクトで実際に動いています。