開発・技術選定

少人数開発の Git 運用 — ブランチとレビューをどこまで決めるか

2019年08月07日 · by IT.Skill

少人数の開発に大規模向けのブランチ戦略を持ち込むと、手続きだけが増えて速度が落ちます。
実際に機能している最小限のルールを整理します。

main        … 常にデプロイ可能な状態
feature/*   … 作業用（マージしたら消す）

リリースブランチや develop は、リリースを束ねる必要が出てから作ります。
継続的にデプロイするなら不要です。

× 修正
× fix bug
○ 支援の重複作成を防ぐため冪等性キーを追加

半年後に git log を読むのは自分です。
変更内容はコードを見れば分かりますが、理由は書かないと残りません。

レビュアーがいなくても、PR を作る意味があります。

自分でマージする前に、差分を一度通しで読むだけで品質が変わります。

git pull --rebase          # マージコミットを増やさない
git commit --amend         # 直前の修正はまとめる（push 前のみ）

push した後の --amend や rebase は、他人の作業を壊すので避けます。
1人でも、複数の環境で作業していると同じ問題が起きます。

一度コミットすると、履歴から消すのは非常に面倒です。最初から防ぎます。

.env
*.pem
db.sqlite3
staticfiles/
__pycache__/

コミット前に機械的にチェックする仕組みを入れておくと確実です。

# .git/hooks/pre-commit
if git diff --cached --name-only | grep -qE '\.env$|\.pem$'; then
    echo "秘密情報が含まれています"; exit 1
fi

git tag -a v1.2.0 -m "請求書PDF出力を追加"
git push --tags

障害時に「いつのバージョンから発生したか」を特定できます。
本番デプロイのたびにタグを打つ運用にしておくと、切り戻しも簡単です。

関連記事