「Git は一応使えるけれど、コンフリクトが起きると冷や汗が出る」「なぜ
main に直接 push してはいけないのか、実は腹落ちしていない」Git/GitHubは、現代の開発現場における「呼吸」のような存在ですが、その仕組みを曖昧に理解していると、重大なデグレや作業停滞を引き起こす原因になります。本記事では、実務での失敗談と成功体験をもとに、「チームで開発を円滑に進めるための Git/GitHub の鉄則」 を解説します。
1. GitとGitHub：道具と場所の明確な区別#
Git は「あなたの履歴を守る道具」#
Gitは、あなたのPC（ローカル環境）で動作し、「誰が・いつ・どこを」変更したかを秒単位で記録します。
- スナップショット: コミットは単なるバックアップではなく、その瞬間の「設計図」の記録です。
GitHub は「チームの合意形成を行う場所」#
GitHubは、Gitリポジトリをクラウド上に置き、「コードレビュー」という対話を通じて品質を担保するプラットフォームです。
- Pull Request (PR): 「この変更を取り込んでもいいですか？」という提案と、それに対する承認プロセス。
2. チーム開発の品質を決める「コミットメッセージ」#
プロの現場では、コミットメッセージは「未来の自分や仲間への手紙」です。Conventional Commits のような規約を意識しましょう。
feat: ログイン機能にパスワード再設定を追加
fix: バリデーションエラー時の遷移先を修正
docs: README にデプロイ手順を追記
chore: パッケージのアップデート- メリット: 何をしたかが一目で分かり、自動化（リリースノート作成など）にも繋がります。
3. 実務で必須の「リカバリ」コマンド集#
「やらかした！」と思ったときに知っているだけで救われるコマンドです。
直前のコミットを修正したい#
git commit --amend -m "正しいメッセージ"※ Push前のコミットに限ります。
間違えてコミットしてしまった（履歴ごと消したい）#
git reset --soft HEAD~1変更内容は残したまま、コミットだけを取り消せます。
すでに Push 済みのコミットを取り消したい#
git revert [コミットハッシュ]「取り消した」という新しい履歴を作るため、公開リポジトリでも安全です。
4. コンフリクト（衝突）を恐れない戦略#
コンフリクトは「エラー」ではなく、「同じ箇所を修正したよ」というGitからの親切な通知です。
解消のコツ#
- 最新の
mainを取り込む:git pull origin mainまたはgit rebase main。 - 差分を比較する: VS Code などのエディタを使い、「どちらのコードを採用するか」または「両方を統合するか」を判断します。
- チームメイトに聞く: 迷ったら、その箇所を修正した本人に「どっちが正しい？」と聞くのが最短ルートです。
5. プロの workflow：Rebase vs Merge#
- Merge: 履歴の枝分かれをそのまま残す。「いつマージしたか」が明確。
- Rebase: 履歴を一本に整える。コミットログが綺麗になり、後からの追跡が容易。
現場によってルールは異なりますが、「PRを出す前に自分のブランチを最新の main で rebase する」 のが、綺麗な履歴を保つための一般的な作法です。
まとめ：Git は「自由」を手に入れるためのツール#
Gitを使いこなせれば、「いつでも過去に戻れる」「誰の作業も壊さない」という安心感が手に入ります。
git statusを指癖にする。- 意味のある単位でコミットする（1コミット1機能）。
- PR は「相談」の場。早めに出してフィードバックをもらう。
この 3 点を意識するだけで、あなたの開発スピードと信頼性は劇的に向上します。
