開発の道具（Git・コンテナ・ビルド）

コミットは「あとで読む人（未来の自分）」への記録です。1つのコミットに1つの理由を目安にし、整形・名前の変更のような機械的な変更は、中身の変更と分けます。

「なぜ」はコードからは読み取れないので、メッセージや PR の説明に残します。git log -p・git blame で過去の理由をたどれると、調査がずっと速くなります。

どの戦略でも、ブランチの寿命が長いほどコンフリクトと統合の手間が増えます。大きな機能は Feature Flag で隠して小さくマージします。

タグとリリース

リリースした版には git tag -a v1.4.0 -m "…" で印を付け、どのコミットが本番かを分かるようにします。版の番号はセマンティックバージョニング（壊す変更・機能追加・修正 ＝ メジャー・マイナー・パッチ）がよく使われます。GitHub の Releases でタグに変更点を添えたり、タグの push を合図に CI でデプロイしたりします。

レビューの待ち時間は開発の速さを大きく左右します。チームで「1日以内に一度見る」などの目安を決め、形式の指摘は lint と formatter に任せて、人は中身に集中します。

他の人と共有しているブランチを rebase しないのが基本です。履歴が書き換わり、相手の手元と食い違います。自分のブランチを rebase して push し直すときは、相手の変更を消さないよう git push --force-with-lease を使います。

コンフリクトの解き方

<<<<<<< HEAD（自分）
const limit = 50;
=======
const limit = MAX_LIMIT;
>>>>>>> main（相手）

• どちらかを選ぶのではなく、両方の変更の意図を確かめて合わせる（相手の PR を読む）。
• 解いたらビルドとテストを通す。印（<<<）の消し忘れは CI で見つける。
• コンフリクトが多いのは、ブランチの寿命が長いか、同じファイルを多くの人が触っている合図。

秘密情報を push してしまったら、公開された時点で取られた前提で動きます。最初に鍵を無効化・入れ替えし、そのあと必要なら git filter-repo などで履歴から消します（全員の手元の複製にも残るので、消すだけでは解決しません）。GitHub の secret scanning の push protection を有効にすると、既知の形式の鍵を含む push を止められます。

鍵のローテーションと漏えい時の対応

コンテナの中で書いたファイルは、コンテナを作り直すと消えます。DB のデータやアップロードされたファイルは、ボリュームや外部のストレージに置きます。

SRE の「コンテナの仕組み」

# ---- ビルド用
FROM node:24-slim AS build
WORKDIR /app
RUN corepack enable
COPY package.json pnpm-lock.yaml ./      # 先に依存だけ（キャッシュが効く）
RUN pnpm install --frozen-lockfile
COPY . .
RUN pnpm build && pnpm prune --prod    # 開発用の依存を外す

# ---- 実行用
FROM node:24-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
USER node                               # root で動かさない
EXPOSE 3000
CMD ["node", "dist/server.js"]

# compose.yaml
services:
  db:
    image: postgres:17
    environment: { POSTGRES_PASSWORD: dev }
    ports: ["5432:5432"]
    volumes: [dbdata:/var/lib/postgresql/data]
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 2s
  redis:
    image: redis:8
    ports: ["6379:6379"]
  web:
    build: .
    ports: ["3000:3000"]
    environment:
      DATABASE_URL: postgres://postgres:dev@db:5432/postgres
      REDIS_URL: redis://redis:6379
    depends_on:
      db: { condition: service_healthy }
volumes:
  dbdata:

• コンテナどうしはサービス名（db・redis）で互いに届く。手元から使うときは ports で出した localhost:5432。
• depends_on は起動の順番だけ。DB が受け付けられるまで待つには healthcheck と service_healthy。
• DB だけ compose で動かし、アプリは手元で pnpm dev にすると、ファイルの変更の反映が速い（特に macOS）。
• DB の版は本番にそろえる。ここに書くパスワードは手元専用の値にする。

手元の compose と本番（Kubernetes・ECS など）では、ネットワーク・ログの出し方・設定の渡し方・台数が違います。本番では、ログは標準出力に出し、設定は環境変数で受け、どのコンテナがいつ止められてもよいように作ります。

SRE の「コンテナと仮想マシンの比較」

開発サーバーが遅いときは、まず起動時と変更時のどちらが遅いかを分けます。巨大な依存を毎回変換していないか、アイコンやライブラリを丸ごと読み込んでいないかを確かめます。

SRE の「JSバンドルとバンドラー」

キャッシュは「鍵が正しいこと」がすべてです。鍵に入れ忘れた入力があると、古い成果物が使われて、手元と CI で結果が変わる事故になります。

SRE の「ビルド・CIの高速化」

モノレポでは、パッケージどうしの依存の関係から、変更の影響を受ける所だけをビルド・テストします。

# pnpm：main から変わったパッケージと、それに依存するものだけテスト
pnpm --filter "...[origin/main]" test
# Turborepo：入力が同じタスクはキャッシュから（リモートキャッシュも使える）
turbo run build test --affected

共通の部品を変えると多くのパッケージが対象になるので、共通部品は小さく安定させておきます。