Git 和非否認

本文實際上與 DVCS 有關，而不僅僅是 git per se。但我們將聚焦於 git，因為它仍然是當今最受歡迎的 DVCS。

不可否認.

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

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

使用Apache 軟體基礎.

這有什麼重要性？適合初學者，讓我對 Apache 承諾者的提供者授權合約 (ICLA) 需求有共同的誤解。許多人似乎不瞭解到，就算是承諾者的個人著作，在適用語言之間沒有差異ICLA 系列 以及Apache 授權 2.0.

接著提供哪些推送記錄是回溯追蹤的方式，針對發行版本中的每一行程式碼，負責將該程式碼推送至 ASF 的 git 儲存區域的個別確認者。這對於判斷第三方對 Git 貢獻的證明非常重要，因為 DVCS 承諾日誌的分散式本質，讓這類貢獻者「走出去」對 Git 專案的貢獻不幸。責任方隨後，根據 ICLA 成為推送程式碼的承諾人。

早期及妥善的緩解策略全都涉及撤除放棄的貢獻，但可能已經對項目造成損害。若沒有推播記錄，除了在問題追蹤器或清單通訊中追蹤替代記錄之外，我們真的沒有權威性程序來判斷程式碼實際如何進入我們的儲存區域。僅倚賴合併確認日誌來判斷證明，並不令人滿意於安全觀點，因為這需要嚴格遵守特定類型的工作流程 (我們不想要指定)。

如果沒有這樣的話，我們就需要至少授權 PGP 簽署每個貢獻者的承諾，這對許多專案來說相當麻煩。推播記錄提供的透明處理不會影響專案的工作流程，但可確保 ASF 的 Git 儲存區域是真正的主儲存區域。

• 日期：2023-01-19 22:58:40 +0000 (2023 年 1 月 19 日星期四) $*