科技 · 實用指南
Git push 顯示「pre-receive hook declined」？改寫提交前先保留遠端原因
這段摘要只證明遠端在更新引用前拒絕操作，不能指出違反哪項規則。先保存遠端訊息、引用映射與規則負責人，再只修復已證實的邊界。
把「pre-receive hook declined」視為遠端決策的位置，而不是原因。真正的證據通常在前面的 remote 輸出、精確引用更新與主機政策。
在 reset、強推、刪檔或要求管理員放寬規則前，先建立去識別拒絕台帳，再把修復交給控制該邊界的人。
1. 固定精確拒絕現場
保存從第一行 remote: 到所有被拒引用的完整輸出。記錄去識別遠端 URL、傳輸、本機來源、遠端目的、有效帳號、時間與 Git 版本。
不要先 reset、rebase、強推或刪檔，否則可能破壞判定哪個提交、路徑、簽章、物件或引用觸發拒絕所需的載荷。
2. 證明決策執行位置
Git 文件說明 pre-receive 在接收端更新前讀取舊物件 ID、新物件 ID 與完整引用名。非零結果會拒絕接收，因此本機鉤子繞過無關。
區分 pre-receive、逐引用 update 拒絕與 post-receive 錯誤。保留括號理由和全部 remote 訊息，平台可能用通用摘要包裝政策引擎或自訂鉤子。
3. 依第一條具體訊息分流
若主機指出受保護分支、權限、提交訊息、作者電郵、簽章、檔名、大小、標籤刪除、秘密或缺少 LFS 物件，就核對該規則與範圍，不要套用熱門原因。
沒有有效訊息時，由維護者檢查推送規則和受保護引用，伺服器管理員檢查鉤子、日誌與逾時；貢獻者保留失敗引用和新舊 ID。
4. 編輯前證明違規載荷
映射每個來源與目的，將擬推送範圍和遠端引用比較。只按已指出的規則檢查提交資料、路徑、物件大小、簽章與 LFS 指標；多引用要逐一舉證。
記錄失敗物件或政策檢查及其負責人。貢獻者可修訂提交或補傳 LFS，維護者可調整權限或專案規則，只有伺服器所有者能修復自訂鉤子或逾時。
5. 最小修復並驗收
只變更已證實的邊界，再重試同一引用更新。不要為單次推送削弱共享規則；除非遠端允許且確實要改寫歷史，否則不要強推。
確認遠端引用指向預期物件 ID、全部引用均被接受，並保留去識別拒絕與驗收記錄。若仍只有通用訊息，回到最早未解釋的 remote 行或伺服器日誌。
