初心者向けGemini CLI × GitHubで更新していく

ローカルで直して → きれいな履歴でGitHubに上げて → PR（レビュー部屋）でマージする。そのために、小さなブランチ運用＋Geminiで説明文を自動化します。

---

この記事でやること（ゴール）

次にやること: ここを読んだら、あなたは attrip/picture_diary をローカルに落として、小さな修正をPRで出せるようになります。

• URLが何を指すのか（tree/・blob/・compare/・pull/）を理解
• ブランチを切って小さく直す
• Gemini CLIで良いコミット文/PR本文を自動生成
• PRをSquashでマージ、ブランチを片付ける

---

サンプル対象のURLを分解して理解する

次にやること: URLの意味を掴んで、状況に応じて「どのURLを人に渡すか」を即決できるようにする。

• リポの玄関：https://github.com/attrip/picture_diary
  • github.com＝ホスト、attrip＝オーナー名、picture_diary＝リポ名
• ブランチの中身：https://github.com/attrip/picture_diary/tree/main（= mainブランチのファイル一覧）
• 特定ファイル：https://github.com/attrip/picture_diary/blob/main/<path/to/file&gt;（= ファイルを1点表示）
• 差分の全体像：https://github.com/attrip/picture_diary/compare/main...feat/sample（= mainと作業ブランチの差）
• PR（レビュー部屋）：https://github.com/attrip/picture_diary/pull/<番号&gt;（= 会話・差分・チェックが集約）
• コミット1件：https://github.com/attrip/picture_diary/commit/<sha&gt;（= その変更だけ）

覚え方：tree＝ブランチ/フォルダ、blob＝ファイル、compare＝差分、pull＝PR。

---

初回だけ：ローカルにクローン

次にやること: リポを手元に落とし、今後はこのフォルダで作業する。
まずは、ターミナルで自分がローカルに落としたところで作業をするということ。

git clone https://github.com/attrip/picture_diary.git
cd picture_diary

# まだならGitの名義を設定
git config --global user.name  "あなたの名前"
git config --global user.email "あなたのメール"

名義設定済みなら

git clone https://github.com/attrip/picture_diary.git
cd picture_diary

---

毎回の冒頭：最新を取り込んで作業ブランチを切る

次にやること: mainを最新化→必ず「小さな作業用ブランチ」を作成。

git pull origin main
git switch -c feat/<sample_today> 
 # 例: feat/diary-2025-09-11-copy

• 1ブランチ=1テーマ（文言修正と大規模リファクタを混ぜない）

---

変更する：まずは自分で最小修正、迷いどころだけGeminiに聞く

次にやること: エディタで直す→判断が要る所をGeminiに投げて“方針”だけもらう。

gemini -p "目的: picture_diary のトップ文言を初見向けに簡潔化。
最短の具体的変更手順を3〜5ステップ。起こりがちな落とし穴も列挙。"

コツ：パッチ全部お任せはNG。小さく使うほど事故らない。

---

壊れていないか確認（プロジェクト既定のコマンドで）

次にやること: 動作・ビルド・テストのどれかで“最低限の正常性”を確認。

# 例：プロジェクトの流儀に合わせて
npm run build   # or: npm run dev / npm test / pytest / etc.

---

ステージング → コミット（コミット文はGeminiで量産）

次にやること: 変更を載せ、意味が伝わるコミット文をAIで生成→コミット。

git add -A
git diff --staged | gemini -p \
"Conventional Commit形式。タイトルは72字以内（日本語可）。
本文は変更点/理由/影響/テスト観点を箇条書きで簡潔に。" > COMMIT_MSG.txt
git commit -F COMMIT_MSG.txt

• 履歴が読み返せる＝将来の自分/他人のコストが激減。

---

プッシュ → PR作成（レビュー部屋を開く）

次にやること: リモートへ公開→PRを作ってURLを共有。
用語を説明

1. プッシュ (git push)

• 意味: 自分のPCのローカル環境で作業したコードを、GitHubなどのリモートリポジトリにアップロードすること。
• イメージ: 「自分の部屋（ローカル）で作った資料を、会社の共有フォルダ（リモート）にコピーする」。

---

2. PR (Pull Request)

• 意味: 自分の作業ブランチを「mainブランチに取り込んでほしい」とリクエストする機能。
• レビュー部屋を開く: このPRを作ると、GitHub上で「変更内容を確認できるページ」が自動でできる。
  チームメンバーはそこでコメントしたり、コードレビューを行う。

---

3. レビュー

• 意味: 他の人が「このコード大丈夫？」「こう直した方がいいよ」とチェックする工程。
• OKが出れば: そのPRはマージ（merge）され、mainに反映される。

---

4. 全体の流れ

1. ブランチを作る:
   git switch -c feat/〇〇
2. 作業する → commit する:
   git add . → git commit -m "変更内容"
3. push する:
   git push origin feat/〇〇
4. GitHub上でPRを作成する:
   「レビュー部屋」ができて、他の人が確認可能になる。
5. レビュー → マージ:
   承認されれば main に統合される。

---

5. 例え話（カジュアル）

• push = 作った原稿をみんなの共有フォルダにアップする
• PR = 「この原稿、正式な資料に採用して！」と依頼する
• レビュー = みんなで赤ペンチェックする
• マージ = 採用が決まって正式資料に組み込まれる

git push -u origin $(git branch --show-current)
# ブラウザで 'Compare & pull request' → PR作成

• PRのURL（例）：https://github.com/attrip/picture_diary/pull/123
• 差分の全体像：https://github.com/attrip/picture_diary/compare/main...<ブランチ名&gt;

（高速化オプション：GitHub CLI）

gh pr create --fill --base main --head $(git branch --show-current)

---

レビュー対応 → マージは「Squash」、ブランチ削除

次にやること: PR上で会話→通ったら Squash and merge → Delete branch。

• Squash＝コミットを1つにまとめて履歴がきれい
• 終わったブランチは消す（次の作業にノイズを残さない）

---

（必要に応じて）Geminiに小パッチを作らせて当てる

次にやること: 小さいファイル限定でUnified diffを作らせ、git applyで適用。

# 例：docs/index.html の軽微なタイポ修正
cat docs/index.html | gemini -p "ファイルパスは docs/index.html。
明らかなタイポがあれば修正。Unified diff だけを出力。" > change.patch

git apply --index change.patch   # 当たれば即ステージング

当たらない時は手で直すほうが速い。万能ツールだと思わない。

---

トラブル最短脱出

次にやること: まずは落ち着いて、この3パターンを使い分け。

• mainが進んでコンフリクト git pull --rebase origin main # 衝突を直す → git add -A git rebase --continue
• 直前のコミットをやり直し git reset --soft HEAD~1 # 変更はステージ状態で保持 # 全撤回なら git reset --hard HEAD~1
• 違うブランチで作業してしまった git switch -c feat/correct-branch git push -u origin feat/correct-branch

---

命名と運用ルール（最小で効く）

次にやること: チーム/自分のREADMEに貼って、運用を固定化。

• ブランチ：feat/… fix/… docs/…
• 1ブランチ=1テーマ（300行超えたら分割検討）
• コミット1行目は72文字以内
• マージはSquash、終わったらブランチ削除

---

なぜこの順番か（思考の筋）

次にやること: 迷ったら“原理”に戻る。

• 小さく切る→壊さない→説明できる
• Geminiは説明文と小パッチで生産性を上げる（設計と最終判断は人間）
• URLの意味を理解して適切なリンクを貼る＝レビューが速く、誤解も減る

---

代替アプローチ（状況次第で選ぶ）

次にやること: 自分の現場に合う運用を選択。

• 完全Web運用：リポトップで .（ドット）→Web版VS Code→そのままPR
• GitHub Desktop：GUI派に有効（学習コスト低）
• 厳格品質運用：GitHub Actionsで lint/test を必須化。赤PRはマージ不可
• CLI高速運用：gh pr create / gh pr merge --squash --delete-branch

---

今日のアクション（5分で着手）

次にやること: まずは1本、小さくPRを回して“成功体験”を作る。

1. クローン → git pull origin main
2. git switch -c feat/<小テーマ>
3. 最小修正 → npm run build 等で確認
4. git add -A && git diff --staged | gemini ... > COMMIT_MSG.txt && git commit -F COMMIT_MSG.txt
5. git push -u origin <branch> → PR作成（URLを共有）