概要（GitHubは「変更履歴を安全に共有・同期する場所」、Gitはそのエンジン）
Gitはローカルでコードの変更履歴を管理するツール、GitHubはその履歴をクラウドで共有・レビュー・公開する場です。まずは「リポジトリ作成→変更を記録（コミット）→クラウドへ同期（プッシュ）→安全に改善（ブランチ→プルリク→マージ）」の型を身につけます。重要なのは、変更の粒度（小さく、意味のある単位）、ブランチで壊れない進め方、.gitignoreで秘密や生成物を入れないことです。
最初の型（リポジトリ→コミット→プッシュの一連の流れ）
リポジトリを作る（ローカルから開始）
# 新規プロジェクト
mkdir myapi && cd myapi
# Gitを初期化（隠しフォルダ .git が作成され履歴管理が有効に）
git init
# 最低限のファイル
echo "# My API" > README.md
echo "venv/" > .gitignore
echo "__pycache__/" >> .gitignore
- ポイント: .gitignoreは「コミットしないもの」（仮想環境、キャッシュ、秘密）を列挙します。
変更を記録する（ステージ→コミット）
git add README.md .gitignore # ステージ（記録候補に載せる）
git commit -m "プロジェクト初期化" # コミット（履歴へ確定）
- ポイント: メッセージは「何を、なぜ」短く具体的に。後で自分と他人が理解できます。
GitHubへ同期（リモート登録→プッシュ）
# GitHubで空のリポジトリを作成した後（例: https://github.com/user/myapi）
git branch -M main # メインブランチ名をmainへ
git remote add origin https://github.com/user/myapi.git
git push -u origin main # 初回は -u で追跡設定
- ポイント: 以降の更新は、add→commit→pushの繰り返しが基本線です。
安全な改善の型（ブランチ→プルリク→マージ）
変更はブランチで行う（mainを常に安全に）
git checkout -b feature/add-health-endpoint # 新機能用ブランチ
# 変更を加える（例: app.py を編集）
git add app.py
git commit -m "Healthチェックエンドポイント追加"
git push -u origin feature/add-health-endpoint
- 狙い: main（デプロイ対象）を壊さず、枝で自由に試せる状態を保つ。
プルリクエスト（レビューしてから取り込む）
- 手順: GitHubで「Compare & pull request」を作成 → 差分と目的を説明 → レビュー/CI合格 → マージ。
- ポイント: 説明は「背景・変更点・影響範囲」。レビューが通れば品質と安全性が上がります。
競合の解消（同じ箇所を両者が編集）
# 最新を取り込む
git fetch origin
git merge origin/main # 手元にmainを取り込み（または rebase）
# コンフリクト箇所の <<<<<<< >>>>>>> を手作業で正す
git add 修正したファイル
git commit # マージコミット
- 考え方: 片方の意図を残しつつ、動作が整合するように編集。テストが通るか必ず確認します。
Web/APIに効く運用（構成・秘密・自動化の入口）
フォルダ構成の最小型
myapi/
README.md
.gitignore
requirements.txt
src/ # アプリ本体
app.py
tests/ # テスト
- ポイント: 役割ごとに分け、READMEに起動方法・依存・使い方を明記しておくと協力者が増えます。
秘密情報は入れない（.envは除外）
venv/
__pycache__/
.env
secrets/
- 原則: APIキーなどは環境変数やシークレット管理で注入。コミット履歴に載せない。
最初のCI（テストを自動で回す）
# .github/workflows/test.yml
name: test
on: [push, pull_request]
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11'
- run: pip install -r requirements.txt
- run: pytest -q
- 効果: プルリク作成時に自動テスト。壊れた変更がmainへ入るのを防げます。
よく使う基本コマンド（迷ったらここへ戻る）
日々の更新と履歴の確認
git status # 現在の状態（変更/未追跡）
git add <file> # ステージ
git commit -m "説明" # コミット
git push # リモートへ同期
git log --oneline --graph # 履歴を簡易表示
ローカルを最新へ同期
git pull # originの最新を取得して反映
変更の取り消し・やり直し
git restore <file> # 直近コミットの内容へ戻す（未コミット分）
git revert <commit> # 指定コミットを「打ち消す」新コミットを作る
git reset --hard <commit> # 履歴を巻き戻す（破壊的なので慎重に）
- 指針: 共有済み履歴は revert、ローカル未共有なら reset でも可。安全第一で。
例題（FastAPIの小さな変更を安全に進める）
1. 新機能追加をブランチで
git checkout -b feature/add-ping
# src/app.py
from fastapi import FastAPI
app = FastAPI()
@app.get("/ping")
def ping():
return {"ok": True}
git add src/app.py
git commit -m "pingエンドポイント追加"
git push -u origin feature/add-ping
2. プルリクでレビュー・テスト
- GitHubでPR作成、説明に「用途、影響、テスト方法」を記載。
- Actionsでpytestが通ることを確認してマージ。
3. バグ修正を小さく
git checkout -b fix/ping-typo
# 修正 → コミット → プッシュ → PR
- コツ: 1コミット1意図。レビューする人が「差分だけ」見て理解できる粒度に。
落とし穴の回避（巨大コミット・秘密漏えい・main直push）
巨大コミットは読めない
- 対策: 関連する変更だけを小分けに。フォーマット変更とロジック変更を分離。
秘密漏えいは履歴に永続
- 対策: .gitignore、レビューでチェック、誤コミットは履歴から削除＋キー失効。まず漏らさない設計を。
mainへ直接pushは事故のもと
- 対策: ブランチ＋PRを基本運用に。保護設定（branch protection）で「PR経由のみ」にする。
まとめ（小さく記録し、ブランチで安全に育て、GitHubで共有する）
型は「init→add→commit→push」「ブランチ→PR→マージ」。.gitignoreで不要物と秘密を除外し、READMEで使い方を明快に。変更は小さく意味のある単位で記録し、テストを自動化してmainを常に健全に保つ。これを徹底すれば、初心者でも短い手順で「壊れない・追跡できる・チームで育てられる」コード管理が身につきます。
