smart-git-automation

できること

• 関連する変更をインテリジェントに検出してグループ化します
• 変更内容から説明的なブランチ名を自動生成します
• ワークフローを簡素化します：スキャン → ブランチ作成 → コミット → プッシュ → PR を、確認を減らして実行します

使用するタイミング

変更を論理的にグループ化し、手動での確認を減らして、より速くスマートな git ワークフローを実現したい場合に使用してください。

ワークフローの手順

1. スマートな検出とグループ化

並列で実行します：

• git status - 変更内容を確認します
• git diff --stat - ファイルの変更概要を確認します
• git diff --name-only - 変更されたファイルのみを一覧表示します
• git diff --staged --stat - すでにステージングされている内容を確認します

変更を分析し、論理的にグループ化します：

• 同じモジュール／ディレクトリ内のファイル → 関連している可能性が高い
• 最近の編集で一緒に変更されたファイル → 関連している可能性が高い
• 相互に補完する新しいファイル → 関連している可能性が高い

次のような明確な形式で、グループ化した変更を提示します：

📁 Group 1: UI Components
  - src/components/Button.tsx (modified)
  - src/components/Button.test.tsx (modified)

📁 Group 2: API Layer
  - src/api/client.ts (new)
  - src/api/types.ts (modified)

2. ブランチ名の自動生成

変更の主要なパターンからブランチ名を生成します：

• 形式：<type>/<short-description>
• タイプ：feature、fix、refactor、docs、test、chore
• 最も重要な変更ファイル／機能から説明を導き出します
• kebab-case に変換し、最大 50 文字にします
• 例：
  • feature/add-user-auth（認証関連ファイルから）
  • fix/login-validation（バリデーションの変更から）
  • refactor/api-cleanup（API のリファクタリングから）

提案するブランチ名を表示し、一言での確認（または別の名前の入力）を求めます。

3. ブランチ作成とコミットの簡素化

• main/master にいない場合：現在のブランチが提案名と一致するか確認します
  • 一致する場合：そのブランチを使い続けます
  • 一致しない場合：切り替えるか、新しく作成するかを尋ねます
• ブランチを作成します：git checkout -b <branch-name>
• 変更をステージングします：git add <grouped-files>
• 変更内容からコミットメッセージを自動生成します：
  • 1 行目：<type>: <short description>（最大 72 文字）
  • 本文：簡潔な説明を添えた、グループ別のファイル変更
• 生成したメッセージでコミットし、最初にプレビューを表示します
• 続行するか、一言で確認を求めます

4. プッシュと任意の PR 作成

• コミット後に「リモートにプッシュしますか？（yes/no/abort）」と尋ねます
• yes の場合：git push -u origin <branch-name>
• 次に「PR を作成しますか？（yes/no）」と尋ねます
• yes の場合：
  • リモートを確認します：git remote -v
  • フォークの場合：フォークのリモートを使用します（例：mskadu/repo-name）
  • コミットメッセージから PR の説明を自動生成します
  • gh pr create を次の内容で使用します：
    • タイトル：ブランチ名を使用
    • 本文：変更の概要 + ファイルの内訳 + フォローアップのメモ

主なルール

• 関連ファイルを自動的にグループ化しますが、ユーザーが調整できるようにします
• 実際の変更内容からブランチ名を生成し、ユーザーに名前を付けるよう求めません
• 確認を減らします。一言での回答、または確認が必要な箇所を 1 つにまとめます
• シークレット、認証情報、大容量バイナリは決してコミットしません
• PR を作成する前に GitHub リポジトリが存在するか確認します
• ユーザーがどの時点でも「no」と答えた場合、PR の手順を省略します
• 変更のあるブランチがすでに存在する場合は、修正するか、新しいコミットを追加するかを提案します