push｜Gitにおけるpush操作の意味とレビュー運用での注意点

概要

push は、Gitにおいてローカルブランチの変更をリモートリポジトリへ反映する操作です。
この操作は、コードレビューを含むチーム開発における変更共有の起点となります。

基本操作とコマンド例

# 初回push（新しいブランチ）
git push -u origin feature/add-login
# 既存ブランチへのpush
git push
# 強制push（force-push）
git push --force

pushとpull-requestの関係

1. 開発者はローカルで作業・コミット
2. push でGitHubなどのリモートに変更を送信
3. PR（pull-request）を作成してレビューを開始
4. 修正が必要ならローカル修正 → 再度 push

force-pushの取り扱いと注意点

よくあるトラブル

• force-pushで既存のレビューワーコメントが消える
• 差分が一新され、変更内容の比較が困難になる
• CIやステータスチェックが無効になるケースもある

安全な代替策

• git push --force-with-lease を使う（他人の更新を上書きしない）
• 修正用コミットを積み上げて squash はマージ時に行う
• 重大な変更はPRをクローズして新PRを作成

会話例：レビュー中のforce-push対応

Author: force-pushしました。型の定義見直しが主です。前回コメントは維持してあります。
Reviewer: 了解です。差分見直します。前のコメントも活かせるなら助かります。

チーム運用でのベストプラクティス

• force-push の可否をレビュー運用ルールに明記
• main / develop ブランチへの直接pushは禁止（保護ブランチ設定）
• CIでpushトリガーを正しく設定する（on: push）

on:
  push:
    branches:
      - main
      - develop

関連用語

• pull-request：push後にレビューを開始するための申請
• status-check：pushに紐づくCIの成功可否
• rebase：push前の履歴整理操作

実務視点まとめ