Git実践編：特殊コマンド＆CI/CD入門2025

Gitシリーズも第3弾になりました。

第1弾では基本の5コマンド、第2弾ではcherry-pickやrebaseなどの発展コマンドを学びました。

今回は知っていると作業効率が上がる特殊コマンドと、CI/CD（自動化）の世界に足を踏み入れます。

「CI/CDって難しそう...」と思うかもしれませんが、仕組みは意外とシンプルです。この記事を読み終える頃には、GitHub Actionsで自動テストを設定できるようになっています。

この記事で学べること

カテゴリ	内容
特殊コマンド	git tag, git blame, git clean, git submodule, git hooks
CI/CD基礎	CI/CDとは何か、GitHub Actions入門
実装例	自動テスト、自動デプロイの設定ファイル

Part 1: 知ってると便利な特殊コマンド

git tag - バージョンに名前をつける

どういうロジック？

tag（タグ）は「コミットに貼るラベル」です。

リリースのタイミングで「v1.0.0」のような名前を付けておくと、後から「あのバージョンのコード」にすぐ戻れます。

Text

コマンド

Bash

セマンティックバージョニング

バージョン番号には意味があります。

Text

変更内容	上げる番号	例
バグ修正	パッチ	v1.0.0 → v1.0.1
新機能追加	マイナー	v1.0.1 → v1.1.0
互換性のない変更	メジャー	v1.1.0 → v2.0.0

git blame - 誰がいつ書いたか調べる

どういうロジック？

blame（ブレイム）は「各行の作者を表示する」機能です。

名前は「blame（責める）」ですが、責めるためではなく「この行を書いた人に質問したい」「いつ追加されたか知りたい」時に使います。

コマンド

Bash

VS Codeで使う方法

コマンドを打たなくても、GitLens拡張機能を入れると、カーソルを置いた行の作者が自動で表示されます。おすすめです。

git clean - 追跡されていないファイルを削除

どういうロジック？

clean（クリーン）は「Gitが追跡していないファイルを削除する」機能です。

ビルドで生成されたファイルや、一時的に作ったファイルを一掃したい時に使います。

Text

コマンド

Bash

重要: 必ず -n で確認してから -f を実行してください。消えたファイルは復元できません。

git submodule - 別リポジトリを組み込む

どういうロジック？

submodule（サブモジュール）は「プロジェクト内に別のGitリポジトリを埋め込む」機能です。

共通ライブラリやテーマなど、別リポジトリで管理されているコードを取り込む時に使います。

Text

コマンド

Bash

注意点

サブモジュールを含むリポジトリをクローンする人は、--recurse-submodules オプションを付けるか、クローン後に git submodule update --init を実行する必要があります。

git hooks - コミット前に自動チェック

どういうロジック？

hooks（フック）は「Gitの操作に連動して自動でスクリプトを実行する」機能です。

コミット前にリンターを走らせたり、プッシュ前にテストを実行したりできます。

Text

よく使うフック

フック名	タイミング	用途
`pre-commit`	コミット前	リンター、フォーマッター
`commit-msg`	メッセージ入力後	メッセージ形式チェック
`pre-push`	プッシュ前	テスト実行

husky + lint-staged（Node.jsプロジェクト向け）

手動でフックを設定するのは大変なので、Node.jsプロジェクトでは husky と lint-staged というツールがよく使われます。

Bash

JSON

これで、コミット時に変更したファイルだけ自動でリント＆フォーマットされます。

Part 2: CI/CD 入門

CI/CDとは？超やさしく解説

CIとは（継続的インテグレーション）

CI = コードを変更するたびに自動でテストを実行する仕組み

Text

「自分のPCでは動いたのに、他の人の環境では動かない」という問題を早期に発見できます。

CDとは（継続的デリバリー/デプロイ）

CD = テストが通ったら自動でデプロイする仕組み

Text

手作業でのデプロイミスを防ぎ、リリースを高速化できます。

なぜCI/CDが必要？

手動テストの漏れを防ぐ: 毎回同じテストが自動で走る
デプロイ作業を自動化: 「デプロイ忘れ」「手順ミス」がなくなる
チーム全員が同じ品質基準: PRが通る = 最低限の品質が保証される

GitHub Actions 入門

GitHub Actionsとは

GitHubに組み込まれた無料のCI/CDツールです。

パブリックリポジトリは無制限で使える
YAMLファイルを置くだけで設定完了
豊富な既存Actionを再利用できる

基本用語

用語	意味	例え
Workflow	自動化の全体設定	レシピ全体
Job	タスクのまとまり	「材料を切る」工程
Step	個々の処理	「玉ねぎを切る」
Action	再利用可能な部品	「みじん切り器」
Runner	実行環境	キッチン

ディレクトリ構造

Text

.github/workflows/ フォルダにYAMLファイルを置くだけで、GitHub Actionsが自動で認識します。

実装例1: 自動テストの設定

最もシンプルなワークフローを作ってみましょう。

YAML

各行の意味

行	意味
`name: Test`	ワークフローの名前（GitHub上で表示される）
`on: push, pull_request`	いつ実行するか（push時とPR時）
`branches: [main]`	mainブランチへの変更のみ対象
`runs-on: ubuntu-latest`	Ubuntu環境で実行
`uses: actions/checkout@v4`	リポジトリのコードを取得
`uses: actions/setup-node@v4`	Node.js環境をセットアップ
`run: npm ci`	依存関係をインストール
`run: npm test`	テストを実行

実装例2: 自動デプロイの設定

Cloudflare Pagesへの自動デプロイ例です。

YAML

シークレットの設定方法

APIトークンなどの秘密情報は、Secretsに保存します。

GitHubリポジトリの Settings を開く
Secrets and variables → Actions を選択
New repository secret をクリック
名前（例: CLOUDFLARE_API_TOKEN）と値を入力

ワークフロー内では ${{ secrets.名前 }} で参照できます。

実装例3: PRにリンター結果を表示

YAML

これでPRを作るたびに自動でリンターが走り、結果がPRページに表示されます。

よく使うワークフローパターン

やりたいこと	設定
PRごとにテスト	`on: [pull_request]`
mainマージでデプロイ	`on: push` + `branches: [main]`
毎日定時実行	`on: schedule` + `cron: '0 0 * * *'`
手動で実行	`on: workflow_dispatch`

YAML

Part 3: まとめ

特殊コマンド早見表

コマンド	何をする	使う場面
`git tag`	バージョンラベルを付ける	リリース時
`git blame`	誰がいつ書いたか調べる	調査・質問時
`git clean`	追跡外ファイルを削除	クリーンアップ
`git submodule`	別リポジトリを組み込む	ライブラリ管理
`git hooks`	操作に連動して自動実行	品質管理

CI/CD設定の始め方

.github/workflows/ フォルダを作成
YAMLファイル（例: test.yml）を作成
pushしてGitHubにアップロード
リポジトリの Actions タブで結果を確認

最初は自動テストから始めて、慣れてきたら自動デプロイに挑戦してみてください。

Gitシリーズ全体のまとめ

Text

ここまで来たら、あなたはもうGit中級者です。

全部を今すぐ覚える必要はありません。必要な時にこのシリーズに戻ってきてください。

一緒にGitを使いこなしていきましょう。