GitHub push / pullの違い
pushは手元のcommitをGitHubへ送る操作、pullはGitHub側の変更を手元へ取り込む操作です。どちらもbranch、差分、conflictの可能性を確認してから進めます。
このページでわかること
- pushは送る操作、pullは取り込む操作
- branchとremoteを確認してから実行する
- conflictが出たら内容を読んで解消する
まず確認すること
- push前に差分と公開範囲を見る
- pull前にローカル未保存変更がないか見る
- mainへ直接入れずPRで確認できる流れを優先する
やってはいけないこと
- 履歴を書き換える操作を軽く扱う
- conflictを片側だけ見て機械的に消す
- 認証情報が入った変更をそのまま送る
安全寄りに進める手順
- 対象のrepo、branch、PR、Actions runを確認する。
- Secrets、APIキー、token、.env、個人情報が差分やログに出ていないか見る。
- 必要な場合は値を停止または再発行し、影響範囲を整理する。
- 変更は小さなbranchとPRに分け、CIとreviewで確認する。
CodexやAI作業時の注意
AIに作業を渡す時は、対象ファイル、触らないファイル、確認項目を明記します。認証情報や実際のキー値は本文、Issue、PR説明、ログ、レポートに残さないようにします。
公式情報で確認する領域
Actions、Secrets、PR、repository visibility、workflow permissionsは仕様が変わることがあります。実作業前にはGitHub Docsで最新の説明を確認してください。
向きを取り違えないための覚え方
2つの操作は、自分の手元とサーバーのどちらを基準にするかが逆なだけです。名前で覚えようとすると毎回迷うので、向きで覚えてください。
- 送る：手元の変更をサーバー側へ反映する。他の人に見える状態になるのはこちら
- 取り込む：サーバー側の変更を手元へ持ってくる。手元が書き換わるので、作業中のものがあると衝突します
迷った時の指針は単純で、作業を始める前に取り込む、終わったら送るです。この順番を守るだけで、衝突の大半は起きません。逆に、送る前に取り込んでいないと、他の人の変更を巻き戻す形になってしまいます。
衝突が起きた時に慌てない
同じ場所を自分と他の人が同時に直すと衝突します。これは失敗ではなく正常な通知で、システムが「どちらを採るか決めてください」と聞いている状態です。
やってはいけないのは、内容を見ずにどちらかを選んで進めることです。相手の変更を消してしまいます。手順としては、まず両方の内容を読む、次に両方必要なら手で書き足して両立させる、判断が付かなければ相手に聞く。時間はかかりますが、消してしまうより確実に速いです。
1人で使っていて衝突が出る場合は、別の端末や別の画面から変更が入っています。どこで作業したかを思い出してから進めてください。