こんにちは！日々の開発、本当にお疲れ様です。
大規模なリポジトリを運用していると、こんな悩みを持ったことはありませんか？
「機能開発で細かく切ったコミットが、リリースブランチにごちゃごちゃと残ってしまい、リリースノートが汚い……」
「バージョンのタグ付けや、フォーク元のリポジトリへの追従を、うっかり手作業で忘れてヒヤッとしたことがある……」
これをすべて手作業でやろうとすると、ヒューマンエラーの温床になりますよね。実は、GitHub Actionsの裏側で`git`コマンドを巧みに操ることができれば、こうした面倒な作業はすべて自動化し、あなたのチームの開発体験を劇的に向上させることができます。
今回は、GitHub Actionsを使って「Git履歴の美化（コミットの結合）」と「安全な自動タグ付け」を実現するマージ戦略について、基礎から実践まで優しく紐解いていきましょう。これをマスターすれば、毎日のリリース作業が驚くほど楽になりますよ！
—
1. GitHub ActionsとGit操作の基礎：なぜこのテーマが重要なのか？
そもそも、なぜCI/CDツールであるGitHub Actionsで直接Gitの履歴を操作するのでしょうか？
開発者が日常的に行う「コミットをまとめる（Squash）」「タグを打つ」「ブランチを強制プッシュする」といった操作は、一歩間違えるとリモートの履歴を破壊し、チームメンバーの作業を止める大惨事になり得ます。だからこそ、「誰がやっても同じ結果になり、権限管理が厳密なCI環境で、安全な手順をコード化して実行する」ことが、大規模開発の現場では求められるのです。
最初の難所：認証と権限の壁を突破する
GitHub Actionsからリポジトリに変更をプッシュするには、適切な権限（Token）の設定が不可欠です。デフォルトの `GITHUB_TOKEN` は非常に強力ですが、セキュリティ担保のために適切な設定をしないと、「プッシュが拒否された（403エラー）」という壁にぶつかります。
まずは、ワークフローファイル（`.github/workflows/` 配下）でGit操作を行うための「基本のキ」を確認しましょう。
—
2. 【基礎セットアップ】安全にGitを操作するためのワークフロー設計
GitHub Actions上で安全に `git` コマンドを叩くためには、以下の3点に気を配る必要があります。
1. ワークフロー権限の明示（`permissions`）：リポジトリへの書き込み権限を与える。
2. Gitのユーザー情報の登録：誰がコミットしたのかを明確にするため、Botのメールアドレスと名前を設定する。
3. 適切なチェックアウト（`fetch-depth: 0`）：履歴を操作するためには、浅いクローン（shallow clone）ではなく、全履歴を取得する必要がある。
実践：HelloWorld的な「自動コミット＆タグ付け」ワークフロー
まずは、手始めに「ワークフローが走った日時でコミットをまとめ、自動でタグを打つ」最小限のスクリプトを見てみましょう。
name: Git Operations & Auto Tagging
1. ワークフロー全体のトリガー設定
on:
workflow_dispatch: # 手動で安全にテストできるようにする
2. リポジトリへの書き込み権限を明示的に付与
permissions:
contents: write
jobs:
git-cleanup-and-tag:
runs-on: ubuntu-latest
steps:
# 3. 【超重要】全履歴（fetch-depth: 0）を取得する
- name: Checkout Repository
uses: actions/checkout@v4
with:
fetch-depth: 0
# 4. Gitのコミットユーザーを設定（Botであることを明示）
- name: Configure Git User
run: |
git config –global user.name “GitHub Actions Bot”
git config –global user.email “actions@github.com”
# 5. 動作確認（HelloWorld的ステップ）：現在の最新コミットを整理する例
- name: Verify Git Environment
run: |
echo “現在の最新コミット:”
git log -1 –oneline
# 6. 自動タグ付けのサンプル（例：v1.0.0-[ランダム値]）
- name: Create and Push Tag
run: |
TAG_NAME=”v1.0.$(date +%s)”
git tag $TAG_NAME
git push origin $TAG_NAME
echo “Created tag: $TAG_NAME”
このワークフローを `.github/workflows/git-ops.yml` として保存し、GitHubの「Actions」タブから手動実行（`workflow_dispatch`）してみてください。無事にタグが作成されれば、第一段階はクリアです！
—
3. 【実践】大規模リポジトリの履歴を綺麗にする「マージ戦略」
さて、ここからが本番です。
大規模な機能開発ブランチでは、「WIP（作業中）」「修正」「タイポ修正」「さらに修正」といった細かいコミットが何十個も積み重なりがちです。これをリリース前に、「意味のある1つのコミット」に美しく結合（Squash）する自動化を組み込んでみましょう。
衝突（コンフリクト）回避のためのGitHub CLI活用術
シェルスクリプトだけで複雑なGitのコンフリクトを解決しようとすると、スクリプトが破綻してリポジトリが壊れるリスクがあります。ここで強力な相棒になるのが GitHub CLI (`gh`) です。GitHubが公式に提供しているこのツールを使えば、安全にPRの状態を操作できます。
以下は、リリースブランチへのマージ時に、自動で履歴を綺麗に整理するスクリプトの断片です。
- name: Squash and Clean Commit History
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
# 例として、特定のフィーチャーブランチの履歴をインタラクティブではなく論理的に整理する
# 実際には、PRのSquash merge機能や、メインブランチへの取り込み時にスクリプトを適用します
echo “現在のブランチのコミット数を確認します”
git rev-list –count HEAD
# 過去N個のコミットを一つにまとめる安全なテクニック（ソフトリセットの活用）
# ※メインへの直接プッシュは避け、リリース用の一時ブランチで行うことを推奨します
# git reset –soft HEAD~3
# git commit -m “chore(release): まとめたコミットメッセージ”
> 先輩エンジニアからのアドバイス：
> `github.token` を用いてプッシュする際、デフォルトの設定のままだと「無限ループ（自分がプッシュしたアクションが、さらに別のワークフローをトリガーしてしまう現象）」を引き起こすことがあります。これを防ぐために、ワークフローのトリガーには `branches` の絞り込みや、`git push` 時の保護設定を必ず行いましょう。
—
4. トラブルシューティング：現場でよくあるハマりどころ
1. `Protected branch hook declined` エラーが出る
- 原因：mainやmasterなどの保護されたブランチに対して、直接強制プッシュ（`git push -f`）を行おうとした場合に発生します。
- 対策：履歴の書き換えや強制プッシュを伴う操作は、保護されていないリリース用の一時ブランチ（例: `release/v1.x`）で行い、最終的に通常のPull Request経由でマージするようにフローを設計しましょう。
2. タグが重複してエラーになる
- 原因：すでに存在するタグを再度作成・プッシュしようとした場合。
- 対策：タグを打つ前に `git tag -l “v1.0.0″` などで存在確認をするか、タイムスタンプやユニークなハッシュを付与する仕組みを取り入れましょう。
—
まとめ
いかがでしたでしょうか？
今回は、GitHub Actionsを使ったGit履歴の操作と、安全な自動タグ付け・マージ戦略について解説しました。
- 全履歴の取得（`fetch-depth: 0`） を忘れないこと。
- Bot用のGitユーザー設定を確実に行うこと。
- 強力な `GITHUB_TOKEN` の権限管理を正しく行うこと。
これらさえ押さえておけば、大規模リポジトリ特有の「汚いコミットログ」や「タグ付けの付け忘れ」から解放され、開発チーム全体が本質的なコーディングやプロダクトの価値提供に集中できるようになります。
今日からあなたのプロジェクトでも、このスマートな自動化を取り入れてみませんか？ 毎日の作業が、きっと劇的に楽になりますよ！