テクノロジー · 実用ガイド
Git push が「pre-receive hook declined」？履歴を書き換える前に遠隔側の理由を保存する
この要約が示すのは、ref 更新前にリモートが拒否したことだけです。remote 出力、ref 対応、規則の所有者を記録し、証明できた境界だけを直します。
「pre-receive hook declined」は遠隔判断の場所であり、原因そのものではありません。直前の remote 行、正確な ref 更新、ホストの規則が証拠です。
reset、force push、削除、規則緩和の前に秘匿化した拒否台帳を作り、寄稿者・保守者・サーバー管理者の正しい所有者へ修復を振り分けます。
1. 拒否時点を固定する
最初の remote: 行から全 rejected ref までを保存し、秘匿化した URL、transport、source、destination、実行アカウント、時刻、Git 版を記録します。
先に reset、rebase、force push、削除をすると、どの commit、path、署名、object、ref が原因かを示す payload を失う恐れがあります。
2. 判断場所を証明する
Git 文書では pre-receive が old OID、new OID、完全な ref 名を更新前に読むと定義されています。非ゼロなら受信を拒否するため、ローカルフックの回避は無関係です。
pre-receive、ref ごとの update、post-receive の障害を分け、括弧内理由と remote 出力を全部残します。
3. 最初の具体的 remote 行で分岐する
保護 branch、権限、message、author email、署名、filename、size、tag 削除、secret、LFS 欠落が示されたら、その規則と scope を確認します。検索結果の典型原因を代入しません。
説明がなければ maintainer は push rule と protected ref、administrator は hook code、log、timeout を調べます。寄稿者は失敗 ref と old/new OID を保存します。
4. 編集前に違反 payload を証明する
各 source と destination を対応付け、提案 range を remote ref と比較します。指定規則に必要な commit metadata、path、object size、署名、LFS pointer だけを確認します。
失敗 object または policy check と所有者を記録します。commit 修正、権限変更、server hook 修理はそれぞれ別の所有境界です。
5. 狭い修復と完了確認
証明できた境界だけを変え、同じ ref 更新を再実行します。一件のために共有規則を弱めず、許可と意図がない force push はしません。
remote ref の OID と全対象 ref の受理を確認し、秘匿化した拒否・完了記録を残します。通用文だけが残るなら最初の未説明 remote 行か server log に戻ります。
