Git 與非否認，已修訂

這篇文章實際上與 DVCS 有關，不只是一口氣。但我們將聚焦於 git，因為它仍然是當今最受歡迎的 DVCS。

不可否認.

使用傳統的集中式版本控制工具，可從確認歷史記錄輕鬆取得此類記錄。每次確認系統都會經過授權機制，以確保進行變更的人員獲授權上傳該系統。這些記錄對企業而言至關重要，以確保保留準確的記錄，以指出誰負責將每一行程式碼上傳至有問題的軟體。

使用 git 或一般分散式版本控制，「確認」歷史記錄與「上傳」歷史記錄之間有明顯的區別 — 我會將其稱為「推播記錄」。git 中的確認項目不會經過認證，因為它們會在本機進行，而且會在歷史記錄中新增本機未驗證的描述資料。上傳步驟 (aka) 針推

取代為Apache 軟體基金會.

這有什麼重要？入門者好讓我對 Apache 承諾者對於提供者授權協議 (ICLA) 的需求有共同的誤解。許多人似乎不瞭解到，在委員會的個人著作中，適用語言之間沒有差異公司簡介 以及Apache 授權 2.0.

接著提供哪些推送記錄是回溯追蹤的方式，對版本中的每一行程式碼，負責將該程式碼推送至 ASF 的 git 儲存區域的個別確認者。這在確定 Git 第三方貢獻的來源時非常重要，因為 DVCS 確認日誌的分散式本質，讓這類貢獻者不幸地「離開」對 Git 專案的貢獻。接著，根據 ICLA 的責任方會成為推送代碼的承諾者。

早期及妥善的緩解策略全都圍繞去除棄置的貢獻，但該項目的損害可能已經完成。如果沒有推播記錄，除了在發行追蹤器或上市通訊中查看替代記錄外，我們文本上沒有權威性程序來確定該程式碼如何實際進入我們的報告。僅依賴合併確認記錄來確定來源並不非常滿意，因為這需要嚴格遵守特定類型的工作流程，而我們不想要指定。

如果沒有這樣的話，我們就必須至少簽署每位貢獻者的承諾，而這對許多專案來說都是不必要的。推播記錄提供不影響專案工作流程的透明程序，但為了確保 ASF 的 Git 儲存庫是真正的主儲存區域。

2025 更新

Git 有原生支援SSH-SK-ED25519@openssh.com

完整 PGP 基礎架構的無障礙和複雜性不再與解決上述組織或每個專案層級討論的非否認性問題有關。而良好的 GitHub 整合也有助於完全實現此工作。