小さな受託でも main に直接pushしない、その理由

🚧なぜ「一人でも」PRを挟むのか

PRはレビューの場であると同時に、自分の差分を一拍置いて見直す場所。だから一人でも挟む価値がある。

私たちの開発標準は、いたってシンプルです。「コード変更を main / master に直接 push しない。必ず feature ブランチを切って、Pull Request 経由でマージする」。

例外は、日次の観測ログのようなドキュメント系ルーチンだけ。これも所定のポリシーに沿った自動マージに限っています。

一人しかいないのに PR を挟む意味なんてあるのか。最初はそう思っていました。

でも、やってみて分かったんです。PR は「他人にレビューしてもらう場所」であると同時に、「作業を一度立ち止まって、差分を眺め直す場所」でもある、と。

自分が書いた変更でも、diff 画面で赤と緑を通しで見ると気づきます。消し忘れたデバッグコード。意図せず混ざったファイル。 ――受託のサイトを触っているときほど、この「一拍置く」がじわっと効いてきます。

🔀main = 本番、という前提を崩さない

main は常に本番に出せる状態に保つ。中途半端なコードは feature に閉じ込め、迷いを消す。

受託の WordPress でも、自社サービスでも、私たちは main を「いつでも本番に出せる状態」として扱っています。作業中の中途半端なコードは、feature ブランチの中だけに閉じ込める。

この線引きがあるだけで、「今の main を出せばいいんだっけ？」という迷いが消えます。

――ただし、ひとつ気をつけていることがあります。merge と deploy は別だ、という感覚です。

私たちの自社サイトは、マージしただけでは本番に反映されません。別のデプロイ工程が走って、はじめて公開されます。

この前提を忘れて「マージしたから直った」と思い込む。でも実際には本番が古いまま。 ――この事故を、私たち自身がやりました。ブランチ運用を整えるのは、「どこまで進んだか」を追える状態を保つことでもあるんです。

🧨戻せない操作を、日常から外す

reset --hard は選択肢をゼロにする。取り消しは stash と revert に寄せて履歴を残す。

ブランチ運用とセットで決めているのが、「戻せなくなる操作を、普段の手癖から追放する」ことです。

具体的には git reset --hard を使わない。作業中の変更を消したいなら git stash。公開済みのコミットを打ち消したいなら git revert。

revert は「打ち消すコミットを新しく積む」やり方です。だから履歴が残る。必要なら、そこからさらに戻せます。

一方 git reset --hard は、ワーキングツリーの変更を問答無用で捨てます。速い。でも、捨てた瞬間に選択肢がゼロになります。

少人数だと、つい「自分がさっき何をしたか」を覚えている前提で作業しがちです。 ――でも、その記憶がいちばん当てにならない。これが正直な実感です。

⛔force push を「原則禁止」にした痛み

force push は共有履歴を上書きし、CI やデプロイの参照を壊す。だから原則封印にした。

もうひとつのルールが、force push の原則禁止です。

共有ブランチに git push --force をかけると、リモート側の履歴を上書きしてしまう。他の環境や CI が参照していたコミットが、消えます。

一人会社でも無関係じゃありません。CI やデプロイの仕組みが、「別のクライアント」として履歴を見ているからです。

実際に痛かったのは、複数の作業を続けざまにマージしたときの取り回しでした。慌てて履歴を整えようとして、無理な上書きに手を伸ばしかけて――「これは戻せなくなる側だ」と気づいて、止めた。そんな場面が何度かあります。

だから今は、どうしても force が必要な状況になったら、その手前で一度立ち止まって判断する。パフォーマンスの問題じゃなく、可逆性の問題として扱っているわけです。

🧰小さなチームのための最小ワークフロー

ブランチ・PR・stash/revert・force 封印の4点だけ。ツールを増やさず、これを崩さない。

整理すると、私たちが受託でも自社でも共通で回しているのは、次の4つだけです。

①作業は必ず feature ブランチを切る。②main への反映は PR 経由。③取り消しは stash か revert。④force push は原則封印。

ツールは増やさない。この4点を崩さないことだけを、優先しています。

この「フィーチャーブランチ＋PR」という形そのものは、私たちが発明したわけではありません。Web開発では広く知られた基本形です（たとえば Martin Fowler の Feature Branch 解説 や、 GitHub Flow のドキュメント が土台になっています）。

私たちがやっているのは、それを「一人会社の受託」というサイズに合わせて、余計な手順を削ぎ落として運用しているだけ。

🧭まとめ：身軽さと壊れにくさは両立する

ルールは少なく、でも『戻せる』ことだけは譲らない。この最小の保険が、小さなチームほど効く。

少人数の受託だからこそ、ルールは少なく。でも「戻せる」ことだけは、譲らない。

main に直接 push しないのも、reset --hard や force push を避けるのも、根っこは同じです。「あとで戻せる自分を、残しておく」ため。

ブランチと PR という最小限の仕組みは、身軽さを損なわずに、事故ったときの逃げ道をつくってくれます。 ――小さなチームほど、この保険がじわじわ効いてきます。

あなたの現場でも、まずは「main に直接 push しない」の一行だけ、決めてみませんか。そこから始めるので、十分です。