受託でgitを使用する際、触っているのは他人の本番環境であることを前提にしなければいけません。自分のサービスなら壊れても困るのは自分だけですが、案件はそうではありません。
gitの手順を調べれば、コマンドの解説はいくらでも見つかります。それでも「今のやり方で合っているのか」という不安が消えないのは、手順が間違っているからではないと思います。一般に語られるgitの運用は個人開発を前提にしているため、受託とは条件が違います。
この記事では、gitとGitHubの役割を整理したうえで、1人で受託のWeb制作をするときに何を見て決めるかをまとめます。
- gitとGitHubの役割の違いと、Web制作で必要な理由
- 個人開発を前提にした運用が受託に当てはまらない理由
- 1人案件でブランチを切るかどうかを決める3つの判断軸
- 実装を戻したいとき、適切なコマンドを選択するための判断軸
- 納品・引き渡しから逆算して、着手前に決めておく5項目
gitとGitHubとは
gitは、変更履歴を手元に記録して、前の状態に戻せるようにする仕組みです。GitHubは、その履歴を置いて、手元のパソコンの外から取得したり確認したりできるようにする場所です。gitを使う＝GitHubを使う、ではありません。
| 何をするもの | Web制作で効いてくる場面 | |
|---|---|---|
| git | 変更履歴を手元に記録し、前の状態に戻せるようにする | 直したら表示が崩れた、を戻せる |
| GitHub | gitの履歴を置いて、手元の外から取得・確認できるようにする | 相手に渡す・相手から受け取る |
Web制作でgitとGitHubが要るのは、「戻せること」と「渡せること」のためです。「戻せること」は事故の復旧を、「渡せること」は納品と引き渡しを支えます。それぞれ後の章で扱います。
受託で変わるgitの前提
個人開発を前提にした運用がそのまま当てはまらないのは、手順が間違っているからではなく、前提が違うからです。受託には3つの条件が加わります。
| 個人開発で前提になっていること | 受託で変わること |
|---|---|
| 壊しても自分のサービス | 他人の本番が動いている |
| 作りながらずっと触り続ける | 改修する人が自分とは限らない |
| 納品・引き渡しがない | 案件には必ず終わりがある |
3つの条件と判断の関係を図にすると、次のようになります。
まとめると、受託のgit運用は 「壊したとき誰が困るか」「半年後に誰が読むか」「最後に何を渡すか」 の3つから考えられます。
自分だけが困るなら、あとからやり直せます。他人の本番が動いているなら、あとから戻せる状態を先に作っておくほうが安全です。
以降では、この3つを具体的な判断に落とし込んでいきます。
1人でもブランチを切るか
3つのうち「他人の本番が動いている」に対応する話です。
「1人だからブランチは要らない」という主張は、半分は当たっています。同時に進む作業がぶつかる問題は、1人の場合発生しません。一方で、機能や依頼の単位で履歴を区切る効果は1人でもブランチが必要になります。
ブランチを切るかどうかは、次の3つで判断できます。
- 本番が既に動いているか
動いているなら、今の本番と同じ状態の main を残したまま作業できます。 - 公開前に確認の区切りが要るか
先方への確認や自分での見直しを挟むなら、作業を区切る単位が要ります。 - AIエージェントを並列で走らせるか
同時に複数の変更が進むため、1人でもブランチが役に立ちます。
3つとも当てはまらないなら、ブランチを切らなくても回ります。1つでも当てはまるなら、main と作業用ブランチの2本という最小構成から始めましょう。
ブランチ名の決め方
一般に紹介される命名テンプレートは feature/<チケット番号>-<機能名> の形です。ただし個人で受ける案件では、課題のやり取りがチャット等で進み、チケット番号がないことも多いです。
その場合は、依頼内容・日付・連番のどれかを名前に入れるのがおすすめです。命名規則を紹介している出典でも、厳密さより迷わず運用できることが大事だと書かれています。テンプレートに合わせられなくても、後から読む人が分かるかどうかで決めて構いません。
コミットの粒度とメッセージ
3つのうち「改修する人が自分とは限らない」に対応する話です。
後から読む人が検索して辿れるか が判断基準です。改修の依頼は数ヶ月後に来ることがあり、そのとき履歴を読むのは半年後の自分かもしれませんし、納品後の改修を引き継いだ別の人かもしれません。メッセージが自分にしか分からないまま放置されやすいのも、確認する相手がいない1人案件の性質だと思われます。
メッセージは、何をしたかよりも、それで何が変わったかが分かる形にします。
| よくある書き方 | 適切な書き方 | 何が変わるか |
|---|---|---|
修正 | fix: 問い合わせフォームの必須チェックが効かない不具合を修正 | 後から読む人が検索する語が入る |
いろいろ更新 | add: トップページにお知らせ一覧を追加 | 1コミットが1つの目的に収まる |
css修正 | fix: 下層ページの見出し下の余白がスマホで詰まる | どのページのどの症状かが分かる |
先頭に付ける prefix は、次の3つで済むことが多いです。
add:— ページ・要素・機能の追加fix:— 不具合の修正update:— 既存の内容の変更
メッセージ規約を導入するか
Conventional Commits はコミットメッセージの書式を決める取り決めです。feat: fix: のような型を先頭に置く形式で、仕様は Conventional Commits 1.0.0 として公開されています。
こうした規約を入れるかは、自動化したい処理があるかで決まります。賛成側の根拠は changelog の自動生成で、型を手がかりにツールが変更点を拾えます。反対に、形式を整えれば良いメッセージになったと思い込みやすく、中身の情報が薄くなる可能性があります。
目的が違うので、結論も逆になります。受託のWeb制作に changelog の自動生成が要ることは多くありません。あとで検索できる程度の簡単な prefix に留めておくのが現実的だと思われます。
日本語か英語か
作法としては英語という説明をよく見かけますが、実務では日本語で運用している例も出てきます。どちらも最後は「合意があるか」の話になり、正解はありません。1人案件では合意する相手がいないので、後から読む人が分かるほうを選びます。
戻し方はpush済みかどうかで決まる
冒頭で挙げた「戻せること」を実際に使う章です。ここでも「他人の本番が動いている」が前提になります。
reset revert restore stash を4つ覚えても、事故ったその場で選べるようにはなりません。どれを使うかは「push済みか」で決まります。ここは複数の出典が一致しています。
| やってしまったこと | 使うもの | 注意 |
|---|---|---|
| push前の直前のコミットを直したい | commit --amend | push済みのコミットには使わない |
| push済みのコミットを取り消したい | revert | 履歴を書き換えず、打ち消すコミットを足す |
| push前の複数コミットをまとめ直したい | reset | オプションで戻す範囲（履歴だけか、手元の変更までか）が変わる。--hard は変更ごと消えて戻せない |
| 作業ツリーの変更を捨てたい | git restore <ファイル名> | 取り消せない。ファイル名の指定が必須 |
push済みのコミットを reset で消さないのは、ブランチの指す位置が変わり、GitHubに置いた履歴と食い違うからです。revert は履歴を残したまま打ち消すコミットを足すだけなので、GitHub側とずれません。
# push前: 直前のコミットにファイルを入れ忘れた / メッセージを直したい
git add forgotten-file.css
git commit --amend
# push済み: そのコミットの変更を打ち消す（履歴は書き換えない）
# push しないと相手には反映されない
git revert 8f3c1a2
git push
# 作業を中断して別の対応に移る: 変更を退避して、あとで戻す
git stash
git stash pop公式の Pro Git『Git Basics – Undoing Things』 にも、--amend はまだ push していないコミットにだけ使うようにと明記されています。
取り消せない操作
restore（旧 checkout --）と reset --hard は取り消せません。Pro Git は git restore を危険なコマンドとして扱い、そのファイルに加えた変更は失われると警告しています。git restore . のようにまとめて指定すると、作業ツリーの変更が一度に消えます。戻し方を覚える前に、戻せない操作を先に知っておくほうが安全です。
stashは取り消しではなく退避
stash を上の表に入れていないのは、役割が違うためです。変更を取り消すのではなく、いったん脇に置くコマンドで、置いたまま忘れると何を退避したのか分からなくなります。当日中に pop する、日をまたぐなら commit する、という運用が紹介されています。
もう1つ、何が脇に置かれるかにも注意が要ります。新しく作ったファイル（gitがまだ追跡していないファイル）は、既定では退避されません。作業ツリーに残るため、そのままブランチを移ると持ち越されます。
.gitignoreに何を入れるか
3つのうち「案件には必ず終わりがある」に対応する話です。何を履歴に入れるかは、最後に何を渡すかで変わります。
原則は ビルドで再生成できるものは入れない です。手元で作り直せるファイルを履歴に入れても、差分が無駄に増えるだけだからです。
迷わず除外するもの。
node_modules/— インストールし直せる- 環境変数ファイル（
.env等）— 認証情報が入る - WordPress の
wp-config.php— データベースの認証情報が入る - データベースのダンプ
- OSが作るファイル（
.DS_Store等）
ここは順番が大事です。一度コミットしたあとに .gitignore へ足しても追跡は続き、過去の履歴からも中身は消えません。認証情報を含むものは、着手直後に入れておくのが前提です。すでにコミットしてしまった鍵やパスワードは、履歴から消そうとするより、作り直して差し替えるほうが確実です。
一方、案件によって判断が割れるもの。
dist/build/などのビルド成果物- アップロード済みのメディアファイル
ビルド成果物は入れるか
一般論としては、ビルド成果物も除外の対象です。ただし受託では、納品先がビルドできるかどうかで話が変わる可能性があります。先方にビルド環境がない場合や、レンタルサーバーへ成果物を直接置く場合は、実際に成果物をリポジトリへ入れることもあります。
どちらが正しいと決まっているわけではないため、案件の条件ごとに決めると考えたほうが実態に近いはずです。決めるのが遅れると、納品の直前に運用ごと作り直すことになります。
納品と引き渡しを先に決める
冒頭で挙げた「渡せること」を扱う章です。
案件に終わりがあるので、渡し方を決める場面は必ず来ます。そして 渡し方が決まると、gitの運用も決まります。何をコミットするか、リポジトリを誰のアカウントに置くかは、どちらも納品の手段から逆算して決まります。
| 手段 | 相手に必要なもの | 注意 |
|---|---|---|
| zipで渡す | なし | 更新のたびに手渡しになる |
| FTPでサーバーに直接置く | サーバー情報 | 今も標準的な手段 |
| リポジトリに招待する | GitHubアカウント | 個人アカウントの権限はowner / collaboratorの2階層のみ |
| リポジトリごと移譲する | GitHubアカウント | 旧URLはリダイレクトされるが、参照先は直しておく |
Gitでの納品は難しい一方、扱う案件は増えているとされています。移譲の手順は GitHub Docs の Transferring a repository、権限の階層は Permission levels for a personal account repository にまとまっています。
なお、相手がgitを読めるとは考えないほうが安全です。リポジトリを共有しただけでは確認できない相手もいるため、プレビュー用のURLなど別の渡し方も一緒に用意することがあります。
リポジトリは誰のものにするか
自分のアカウントに置くか、先方のアカウントに置くか。納品後に移譲するのか、削除するのか、保守のために残すのか。これは技術ではなく契約の段階で決める話です。着手後に持ち出すと、すでに積み上げた履歴の扱いまで含めて相談することになります。
着手前に決める5項目
ここまでの判断軸は、案件ごとに答えが変わります。なので型として覚えるのではなく、案件の開始時に以下5項目を検討します。
- ブランチを切るか
本番が動いているか / 確認の区切りが要るか / AIを並列で使うか - コミットメッセージの規約と言語
自動化の要件があるか / 合意する相手は誰か .gitignoreに何を入れるか
納品先がビルドできるか- 納品手段
相手が扱えるものは何か - リポジトリの所有者と納品後の扱い
契約の段階で決める
よくある質問（FAQ）
- gitとGitHubはどちらから覚えればよいですか？
gitが先です。手元で戻せる状態を作るのが土台になります。GitHubは相手に渡すときに要るもので、納品手段によっては使わない案件もあります。
resetとrevertはどう違いますか？使い分けはpush済みかどうかで決まります。push済みなら
revert、push前は--amendやresetです。内部の動きを覚えるより、この使い分けを1つ覚えておくほうが事故の場で選べます。ただしresetは--hardを付けると手元の変更ごと消えて戻せません。
- コミットメッセージは日本語でよいですか？
合意があるかどうかで決まり、正解はありません。1人案件では合意する相手がいないので、後から読む人が分かると思われるほうを選択しましょう。
まとめ
- 受託のgitは「壊したとき誰が困るか」「半年後に誰が読むか」「最後に何を渡すか」の3つから決まる
- 意見が割れる論点は正解を探さず、何を見て決めるかに置き換える
- 型を覚えるのではなく、案件の開始時に5項目を埋める
判断軸を持っていれば、案件ごとに条件が変わっても、その場で決め直せます。
