こんにちは！現場で日々コードを書き、パイプラインを極限まで磨き込んでいる先輩エンジニアです。
開発を始めたばかりのころ、「ローカルで動いたから大丈夫！」と思ってコードをマージ（統合）したら、本番環境やチームメンバーの環境を壊してしまった……なんて経験はありませんか？あるいは、コードを変更するたびに手動でテストコマンドを実行する作業に、不毛さを感じていませんか？
大丈夫、今日でその悩みとは永遠にお別れです。
この記事では、バージョン管理の標準ツールであるGit (CLI)と、GitHubが提供する最強の自動化プラットフォームGitHub Actionsを連携させ、現代のエンジニアリングにおける必須スキル「CI/CDパイプライン」をゼロから構築します。
これを一度マスターしてしまえば、あなたのコードは「Push（送信）した瞬間、裏で全自動でテストされ、品質が保証される」ようになります。毎日の開発が劇的に楽になり、自信を持ってコードを書けるようになりますよ！
—
1. なぜ「Git CLI × GitHub Actions」なのか？
具体的な操作に入る前に、まずは全体像と「なぜこの組み合わせが最強なのか」という本質を押さえておきましょう。
役割分担：頭脳と筋肉
- Git (CLI) = 変更履歴を記録し、並行開発を安全に行うための「頭脳（管理システム）」
- GitHub Actions = Pushなどのイベントを検知して、クラウド上でテストやビルドを代行する「筋肉（自動化ロボット）」
この2つを繋ぐのが「ブランチ戦略（開発のルール）」です。
最もシンプルで美しい「GitHub Flow」
本記事では、現代のWeb開発で最も広く使われているGitHub Flowというブランチ戦略を採用します。ルールは驚くほどシンプルです。
[ main ブランチ ] (常に動く綺麗な状態を維持)
│
├─► [ feature/xxx ブランチ ] (ここで作業＆Git Push)
│ │
│ ▼ (GitHub Actionsが自動でテスト実行！✅)
│ │
└◄─────────┴─► [ Pull Request を作成して main へマージ ]
1. 機能開発やバグ修正は、必ず`main`から分やした専用ブランチ（`feature/xxx`など）で行う。
2. 変更をGitHubへ`push`する。
3. 【自動化】 GitHub Actionsが起動し、コードが壊れていないか全自動でテストする。
4. テストが成功（Pass）したら、安心して`main`ブランチへ統合（Merge）する。
手動でのテスト忘れを防ぎ、「機械にできることは機械にやらせる」。これがCI（Continuous Integration: 継続的インテグレーション）の本質です。
—
2. 環境構築とセットアップ
それでは、手元で実際に手を動かしていきましょう！まずは必要な環境を整えます。
ステップ1: Git CLIの動作確認
ターミナル（MacならTerminal、WindowsならGit BashやPowerShell）を開き、以下のコマンドを実行してください。
Gitがインストールされているか確認
git –version
バージョンが表示されればOKです。もし入っていない場合は、[Git公式サイト](https://git-scm.com/)からダウンロードしてインストールしてください。
次に、あなたの開発者情報をGitに教えます（未設定の場合のみ）。
ユーザー名とメールアドレスの設定（GitHubに登録している情報を推奨）
git config –global user.name “Your Name”
git config –global user.email “your-email@example.com”
—
3. GitHubワークフロー（CI）の作成
ここからが本番です。GitHub Actionsに「どんな条件で、何を自動実行させるか」を伝える設定ファイル（ワークフローファイル）を作成します。
ステップ2: ローカルリポジトリの作成
適当な作業用フォルダを作成し、Gitリポジトリとして初期化します。
フォルダを作成して移動
mkdir my-cicd-app
cd my-cicd-app
Gitリポジトリとして初期化
git init
デフォルトブランチ名を main に設定
git branch -M main
ステップ3: ワークフロー定義ファイル（YAML）の作成
GitHub Actionsの設定は、`.github/workflows` というディレクトリの中に YAML（ヤムル）形式のファイルとして配置する決まりになっています。
以下のコマンドでディレクトリを作成しましょう。
mkdir -p .github/workflows
次に、`.github/workflows/ci.yml` というファイルを作成し、以下のコードをそのまま貼り付けてください。コメントを深く読んでみてください。プロが現場で使う設定の「なぜ」が詰まっています。
ワークフローの名称（GitHub上の画面に表示されます）
name: Standard CI Pipeline
【トリガー設定】いつこの自動化を発動させるか？
on:
push:
branches: [ “main”, “feature/” ] # mainまたはfeature/から始まるブランチへのPushで発動
pull_request:
branches: [ “main” ] # mainへ向けたPull Requestが作成・更新された時に発動
【ジョブ設定】実行したい作業の定義
jobs:
test-job:
# 実行環境として「最新のUbuntu（Linux）」の仮想マシンをクラウド上に用意
runs-on: ubuntu-latest
steps:
# Step 1: リポジトリのコードを仮想マシン上にダウンロード（チェックアウト）
- name: Checkout repository code
uses: actions/checkout@v4
# Step 2: テストの実行（ここでは動作確認用のシンプルなシェルコマンド）
- name: Run automated test
run: |
echo “==== 自動テストを開始します ====”
# ここに実際のテストコマンド（npm test や pytest など）が入ります
# 今回は環境チェックとサンプル判定を行います
python3 –version
echo “テスト成功: すべてのコード検証をパスしました！”
—
4. 精度100%の「Hello World」自動化テスト
設定が完了しました！
それでは、CLIからGit操作を行い、「Pushしたらクラウド上で自動テストが走る感動の瞬間」を体験しましょう。
ステップ4: GitHub上にリモートリポジトリを作成
1. ブラウザで [GitHub](https://github.com) にログインします。
2. 右上の「+」アイコンから 「New repository」 を選択します。
3. Repository nameに `my-cicd-app` と入力し、他の設定はデフォルトのまま 「Create repository」 をクリックします。
画面に表示された「…or push an existing repository from the command line」のコマンドをコピーし、ローカルのターミナルで実行します。
ローカルの変更をすべて追加してコミット
git add .
git commit -m “feat: add GitHub Actions CI workflow”
リモートリポジトリ（GitHub）のURLを登録（URLはご自身のものに置き換えてください）
git remote add origin https://github.com/<あなたのユーザー名>/my-cicd-app.git
変更をGitHubのmainブランチへ送信
git push -u origin main
ステップ5: 開発ブランチを切ってPushする（現場のリアルな流れ）
次に、新しい機能を開発する想定で `feature/test-ci` ブランチを作って作業してみます。
feature/test-ci ブランチを作成して切り替え
git checkout -b feature/test-ci
簡単なテスト対象となるコードを作成してみましょう。
サンプルコードの作成
echo “print(‘Hello, CI/CD World!’)” > app.py
この変更をコミットし、GitHubへPushします！
変更の追跡とコミット
git add app.py
git commit -m “feat: add app.py”
新規ブランチをリモートへPush
git push -u origin feature/test-ci
ステップ6: GitHub上で自動テストの成功を確認する！
Pushが完了したら、すぐにブラウザでGitHubのリポジトリページを開いてください。
1. リポジトリのヘッダーにある 「Actions」 タブをクリックします。
2. 今Pushしたコミットメッセージ（`feat: add app.py`）のワークフローが黄色のアイコン（実行中）で動いているはずです。
3. 数秒待つと……緑色のチェックマーク（Pass）に変わります！
 (イメージ)
緑色のチェックマークをクリックして詳細ログを開いてみてください。
先ほど `ci.yml` に書いた `Run automated test` の部分が実行され、`テスト成功: すべてのコード検証をパスしました！` と出力されているはずです。
これが、あなたの手によって構築された初めてのCI/CDパイプラインです！
—
5. 現場で震えるほど役立つ！先輩エンジニアからのプロの知見
最後に、これからプロを目指すあなたに、現場で絶対に役に立つ3つの鉄則をお伝えしておきます。
1. 「Fail Fast（早く失敗させる）」の精神
CIの目的は「100%成功させること」ではなく、「バグを統合前に最速で見つけること」です。
テストが失敗（赤色のバツ印）しても落胆しないでください。「本番環境やチームメンバーのコードを壊す前に、ロボットが気づかせてくれた！ラッキー！」と考えましょう。
2. コミットは小さく、Pushは頻繁に
1週間分の大きな変更をまとめて1回Pushすると、CIが失敗した時に原因の特定が困難になります。
「1機能できたらPush」「バグを1つ直したらPush」という小さなサイクル（Small Commits & Early Push）を意識してください。
3. mainブランチの保護（Branch Protection）
チーム開発では、GitHubの `Settings` > `Branches` から Branch protection rules を設定し、「CIのテスト（緑マーク）が通っていないコードはmainにマージできない」ようにロックをかけます。これにより、ヒューマンエラーによるシステム破損を100%防ぐことができます。
—
まとめ
今回学んだことを振り返ってみましょう。
1. Git CLI でコードの変更履歴を安全にブランチ管理する。
2. `feature/` ブランチで作業し、GitHubへ `git push` する。
3. GitHub Actions が裏で自動起動し、コードの品質を爆速でチェックしてくれる。
これであなたは、「手動テストの恐怖」から解放され、本来集中すべき「価値あるコードを書くこと」に専念できる環境を手に入れました。
この小さな一歩は、将来あなたが大規模なシステムを構築し、何十人ものチームをリードするようになっても変わらない「モダン開発の確固たる原点」になります。
ぜひ、自分の個人プロジェクトや仕事のコードにもこの設定を取り入れてみてください。毎日の開発が、驚くほど軽やかで楽しいものになりますよ！応援しています！