[Skill 名] git-push

GitHubへのワンクリックプッシュ

機能説明

現在のプロジェクトをワンクリックでGitHubにプッシュし、完全なライフサイクルをカバーします。

• 初回プッシュ — 新しいプロジェクトをゼロからGitHubへ
• 日常更新 — ファイルを変更したらプッシュ（commit + push）
• バージョンリリース — タグ付け + リリース作成、ダウンロードファイルを添付可能

核心原則：安全第一。余計なものをプッシュしないよう、確認を怠りません。

作業フロー

ステップ0：環境チェック + モード判断

以下の前提条件を順にチェックし、いずれかが満たされない場合は中止してガイダンスを提供します。

1. gitがインストールされているか

• ❌ → 提示：brew install git、中止
• ✅ → 続行

2. gh CLIがインストールされているか

• ❌ → 提示：brew install gh、中止
• ✅ → 続行

3. ghがGitHubにログイン済みか

• gh auth status を実行してチェック
• ❌ 未ログイン → 提示：gh auth login、中止
• ✅ ログイン済み → アカウント名を記録し、ユーザーに「現在ログイン中のアカウント：[xxx]」と伝え、続行

4. gitユーザー情報が設定されているか

• git config user.name と git config user.email を実行してチェック
• ❌ 未設定 → ユーザーに設定を促す：

  git config --global user.name "あなたの名前"
  git config --global user.email "あなたのメールアドレス"

  中止

• ✅ 設定済み → 続行

5. 現在のディレクトリがgitリポジトリであるか → どのパスに進むかを決定

gitリポジトリではない → 【初回プッシュ】ステップ1から開始
gitリポジトリだが、remoteがない → 「ローカルにgitはあるがリモートと関連付けられていない」
    → まずステップ1の大きなファイルのスキャンを実行（安全を確保）
    → その後、ステップ2にスキップしてリモートを関連付ける
gitリポジトリで、remoteがある → 【既存リポジトリ】モード選択に入る：
    ├── 「日常更新をプッシュ」 → ステップ3Bにスキップ（日常更新）
    ├── 「新しいバージョンをリリース」 → 未コミットの変更があるかチェック
    │   ├── 変更あり → まずステップ3Bを実行し、その後ステップ4に進む
    │   └── 変更なし → 直接ステップ4にスキップ（タグ付け + Releaseのみ）
    └── 「やり直す」
        → ⚠️ 警告：「これにより、すべてのGit履歴（すべてのコミット、ブランチ、タグを含む）が削除され、回復できません。」
        → ユーザーが二次確認後、.gitを削除し、ステップ1から開始

ステップ1：プロジェクトスキャン + .gitignore生成

⚠️ 鉄則：.gitignoreは最初の git add の前に配置する必要があります。先にコミットしてから除外してはいけません。Git履歴内の大きなファイルは完全に削除できず、リポジトリが肥大化し、プッシュが失敗する原因となります。

1.1 ディレクトリサイズのスキャン

du -sh を使用してすべてのトップレベルディレクトリとファイルをスキャンし、サイズ順にソートします。

大きなファイルの段階的処理：

表示形式（例）：

スキャンにより、以下の内容が10MBを超えていることが判明しました：

  1. 109MB  slides/   （PPT + 大きな画像）
  2.  12MB  assets/   （動画ファイル）

⚠️ そのうち slides/ は50MBを超えており、プッシュに非常に時間がかかります。
❌ そのうち recording.mp4 (150MB) はGitHubの100MB単一ファイル制限を超えているため、必ず除外する必要があります。

どれを除外しますか？（番号を入力、または「すべて除外」 / 「すべて保持」）

1.2 機密コンテンツのスキャン（公開リポジトリのみ）

ユーザーが公開リポジトリを選択した場合、追加でスキャンします。

• .env / .env.* — 環境変数/秘密鍵
• *secret* / *credential* / *token* — 秘密鍵ファイル
• *.pem / *.key — 証明書ファイル
• memory/ / MEMORY.md — AIツール記憶ファイル
• プライベートコンテンツと思われるファイル

除外を推奨する項目をリストアップし、ユーザーに各項目を確認させます。

1.3 .gitignoreの生成または更新

.gitignoreが存在しない場合：スキャン結果に基づいて新しいファイルを生成します。

.gitignoreが既に存在する場合：既存の内容を読み込み、新しい除外項目をマージし、差分をユーザーに確認させます。ユーザーの既存のルールは上書きしません。

基本テンプレート：

# macOS
.DS_Store
.AppleDouble
.LSOverride
._*

# Editor
*.swp
*.swo
*~
.vscode/
.idea/

# [以下はスキャン結果に基づいて動的に生成されます]
# 大きなファイル（ユーザーが除外を確認）
[パス1]
[パス2]

# 機密コンテンツ（公開リポジトリの場合のみ）
[パス3]

ユーザーに確認後、ファイルに書き込みます。

ステップ2：ユーザーの決定

1. リポジトリ名（デフォルト：現在のディレクトリ名）

2. 説明（一文、空欄可）

3. 公開 / プライベート

• 公開 → 二次確認：「公開リポジトリは誰でも閲覧できますが、.gitignoreで機密コンテンツが除外されていることを確認しましたか？」
  • 確認しない → ステップ1.2（機密コンテンツスキャン）に戻って再審査し、完了後このステップに戻って続行

4. 同名リポジトリのチェック

• gh repo view [アカウント]/[リポジトリ名] を実行してチェック
• ❌ 存在しない → 続行
• ✅ 既に存在 → ユーザーに伝え、尋ねる：
  • 「別の名前に変更」 → 再入力
  • 「この既存リポジトリを使用」 → 作成をスキップし、直接リモートを関連付ける（ステップ3で使用するためにリポジトリURLを記録）
  • 「削除して再作成」 → ユーザーの二次確認が必要

ステップ3：プッシュ

3A. 初回プッシュ（新規プロジェクト）

以下の順序で厳密に実行します。

1. git init + git branch -m main
2. git add -A
3. git commit -m "init: [リポジトリ名]を初期化"
4. リモートリポジトリの作成（ステップ2でリポジトリが存在しなかった場合）：
   gh repo create [リポジトリ名] --private/--public --description "[説明]" --source=. --remote=origin
   （ステップ2でユーザーが「既存リポジトリを使用」を選択した場合、作成をスキップし、直接：git remote add origin [既存リポジトリURL]）
5. git push -u origin main

3B. 日常更新（既存リポジトリ）

1. 変更のスキャン：git status で何が変更されたかを確認
2. 新規追加された大きなファイルのチェック：
   - 新規ファイルの中に10MBを超えるものがある → ユーザーに確認を求める
   - 新規ファイルの中に単一ファイルで100MBを超えるものがある → 必ず除外、.gitignoreに追加
   - .gitignoreが変更された場合、.gitignore自体も後続の git add の範囲内にあることを確認
3. git add -A
4. git commit -m "[変更内容に基づいてコミットメッセージを自動生成]"
   - コミットメッセージのルール：簡潔で分かりやすく、主要な変更を一文で要約
   - 例：「update: ユーザーモジュールを追加 + ログインバグを修正」
5. git push

プッシュ失敗時の処理

ステップ4：オプション — バージョンリリース（Release）

トリガータイミング

• 初回プッシュ後、一度「バージョンをリリースしますか？」と尋ねる
• 日常更新後、積極的に尋ねない（邪魔を避けるため）
• ユーザーが「バージョンをリリース」「リリースを作成」「タグを打つ」と明示的に指示した場合

フロー

1. バージョン番号の決定

現在存在するタグを読み込む（git tag --sort=-v:refname | head -5）

├── タグが一つもない → v0.1.0を推奨
└── 既存のタグがある → 最新のバージョンを表示し、次のバージョンを推奨（デフォルトはminor +1）
    - v0.1.0 → v0.2.0を推奨
    - v1.2.3 → v1.3.0を推奨
    - ユーザーは任意のバージョン番号をカスタム入力可能

バージョン番号の説明（ユーザー向け参考）：
- v0.1.0 → v0.2.0  小規模な更新（機能追加、内容変更）
- v0.2.0 → v1.0.0  大きなマイルストーン（初の正式リリース、大規模なリファクタリング）
- v1.0.0 → v1.0.1  修正（バグ修正）

2. Release説明

• 前回のタグからのコミット履歴を自動的に読み込む（git log [前回のタグ]..HEAD --oneline）
• 変更の概要を生成し、ユーザーに確認または修正を求める
• 最初のバージョン（履歴タグなし）の場合、すべてのコミットから概要を生成

3. ダウンロードファイルを添付するか

ダウンロード可能なファイルを添付する必要がありますか？（例：Appインストールパッケージ、ツール圧縮ファイルなど）

├── 不要 → タグ付け + Releaseページ作成のみ
└── 必要 → ユーザーがファイルパスを提供
    └── ファイルの存在をチェック → 存在しない場合は再入力を促す

4. 実行

git tag [version]
git push origin [version]
gh release create [version] --title "[リポジトリ名] [version]" --notes "[Release説明]"
# 添付ファイルがある場合：
gh release upload [version] [ファイルパス]

Release失敗時の処理：

• タグが既に存在 → ユーザーに「このバージョン番号は既に使用されています」と伝え、別のものを選択させる
• 添付ファイルが存在しない → パスの再入力を促す
• その他のエラー → エラーメッセージを表示

完了時の出力

✅ プッシュが完了しました！

- リポジトリ：[URL]
- 可視性：プライベート / 公開
- ファイル数：[N] 個
- リポジトリサイズ：[X]
- 除外項目：[.gitignoreで除外された内容をリストアップ]
- Release：[バージョン番号 + URL] / 未作成

核心原則

1. スキャンが最優先

.gitignoreは最初の git add の前に配置されます。大きなファイルが一度Git履歴に入ると、後で削除してもリポジトリのサイズは縮小せず、プッシュの失敗や極端な遅延を引き起こす可能性があります。既存のgitリポジトリでリモートと関連付けられていないプロジェクトも、プッシュ前にまずスキャンする必要があります。

2. 大きなファイルの積極的なブロック

10MBを超えるファイルはユーザーに積極的に尋ねます。50MBを超える場合は遅延の警告を出し、100MBを超える単一ファイルはGitHubのハードリミットにより必ず除外します。日常更新時も新規追加ファイルのサイズをチェックします。

3. 公開リポジトリの二重チェック

公開リポジトリでは、機密コンテンツ（秘密鍵、AI記憶ファイル、プライベート文書）を別途スキャンし、プッシュ前に二次確認を行います。

4. 既存コンテンツを破壊しない

プロジェクトに既に.gitや.gitignoreが存在する場合、デフォルトでは上書きせず、まずユーザーに尋ねます。.gitの削除などの破壊的な操作は、明確に結果を警告し、二次確認が必要です。

5. 各ステップで中断可能

ユーザーはいつでも「停止」または「前のステップに戻る」と言うことができます。ユーザーに反応する機会を与えずに一気に実行してはいけません。

6. 日常更新は軽量に

日常更新ではReleaseについて尋ねず、リポジトリ名も尋ねず、プロジェクト全体を再スキャンしません。新規追加された大きなファイルのみをチェックし、コミット + プッシュで迅速に完了します。

使用例

シナリオ1：新規プロジェクトの初回プッシュ

ユーザー：GitHubにプッシュして

Skill：
→ 環境チェック：git ✅ gh ✅ ログイン済み ✅ gitユーザー設定済み ✅ gitリポジトリではない
→ プロジェクトをスキャン中...10MBを超えるコンテンツを発見：
  - 85MB slides/ → ユーザーが除外を確認
  - 15MB images/ → ユーザーが保持を確認
→ .gitignoreを生成、ユーザーが確認
→ リポジトリ名：my-project、プライベート
→ 初期化 + プッシュ成功
→ 「Releaseを作成しますか？」 → スキップ
→ ✅ 完了

シナリオ2：日常更新

ユーザー：プッシュして

Skill：
→ リモートリポジトリと関連付けられていることを検出
→ 変更のスキャン：3つのファイルを変更、2つのファイルを新規追加（すべて10MB未満）
→ コミットメッセージ：「update: ユーザーモジュールを追加 + 設定ファイルを更新」
→ プッシュ成功
→ ✅ 完了

シナリオ3：バージョンリリース

ユーザー：リリースを作成して

Skill：
→ 現在の最新タグ：v0.1.0
→ 「次のバージョン番号はv0.2.0を推奨しますが、よろしいですか？」
→ 変更の概要を自動生成（コミット履歴に基づく）
→ 「ダウンロードファイルを添付する必要がありますか？」 → 不要
→ タグ付け + Release作成
→ ✅ Release v0.2.0が公開されました！

シナリオ4：プッシュ時に大きなファイルを発見

→ git push 失敗：file recording.mp4 exceeds 100MB
→ 「recording.mp4 (150MB) はGitHubの制限を超えているため、除外する必要があります」
→ .gitignoreに追加、再コミット・プッシュ

(原文がここで切り詰められています)