領先一步
VMware 提供培訓和認證,助您飛速進步。
瞭解更多Spring 團隊將推出簡化的貢獻流程,用 開發者原創證書(DCO) 取代簽署 貢獻者許可協議(CLA) 的要求。該流程將於本週從 Spring Framework、Spring Security 和 Spring Boot 開始,然後推廣到整個 Spring 專案組合。
長期以來,Spring 一直使用寬鬆的貢獻者許可協議(CLA),以便為 Spring 專案、使用者和 Spring 團隊提供法律保護。長期的貢獻者可能記得,簽署 CLA 最初需要透過電子郵件傳送已簽名的 CLA PDF 檔案。Spring 團隊當時需要手動驗證 CLA 已簽署才能接受貢獻。如果沒有 GitHub Apps 等整合,當時這種手動過程在一定程度上是必要的。
為了簡化該流程,我們建立了 CLA 的電子版本,該版本自動驗證拉取請求的作者是否已簽署 CLA。這相比手動流程是很大的改進,但它仍然存在缺點。
雖然電子 CLA 簡化了貢獻,但在為 Spring 貢獻時,貢獻者仍然面臨障礙。CLA 是冗長的法律檔案,可能難以理解。更重要的是,CLA 往往是定製的,因此理解它們的工作必須按專案進行。由於員工和僱主之間的法律要求,開發者經常需要與其僱主合作才能獲得簽署 CLA 的批准。所有這些因素都增加了向 Spring 貢獻時的複雜性。
為了進一步簡化對 Spring 的貢獻,我們決定轉向使用開發者原創證書(DCO)。這仍然為 Spring 專案、使用者和 Spring 團隊提供了相同的保護。
DCO 的好處在於它易於閱讀,並且是許多專案(包括 Linux 核心)的標準。完整的 DCO 可以概括為
為了向專案貢獻,您必須同意開發者原創證書。要確認您同意,您的提交資訊底部必須包含一個 Signed-off-by 尾部標記。例如,它可能如下所示
A commit message
Closes gh-123
Signed-off-by: Rob Winch <[email protected]>
在指定提交資訊時,可以使用 命令列選項 -s 或 –signoff 自動新增 Signed-off-by 尾部標記
git commit -s -m
如果您在 GitHub 中選擇了 保持我的電子郵件地址私密選項,則 Signed-off-by 尾部標記可能如下所示
A commit message
Closes gh-123
Signed-off-by: Rob Winch <[email protected]>
對於已經透過 CLA 檢查的現有拉取請求,無需簽署 DCO。如果拉取請求尚未透過 CLA 檢查,則應使用 DCO 流程。
Spring Framework、Spring Security 和 Spring Boot 專案將於本週(2025 年 1 月 6 日)遷移到此流程。經過成功的試執行期後,我們將遷移所有 Spring 專案以使用此流程。
Spring 使用 DCO GitHub App 新增檢查,強制要求拉取請求中的所有提交都包含一個 Signed-off-by 尾部標記,其值是使用者 GitHub 個人資料中的電子郵件和姓名。
如果您想了解該流程的樣子,DCO 應用在其文件中描述了 流程如何工作,並附帶了預期介面的截圖。
如果 DCO 檢查失敗,您可以點選失敗檢查旁邊的“Details”連結,該連結將解釋檢查失敗的原因以及如何修復。如果您忘記為單個提交新增 Signed-off-by 尾部標記,則可以使用以下命令進行新增
git rebase HEAD~1 --signoff
git push —-force-with-lease origin
開發者原創證書 的條款 c 允許包含來自多個來原始碼的提交包含單個 Signed-off-by 尾部標記。在這種情況下,包含 Signed-off-by 尾部標記表明提交作者證明他們有權根據專案許可提交該提交。
您可以在拉取請求上應用建議的更改。
開發者原創證書 的條款 b 允許修改程式碼,但將您的更改(bug)歸因於另一個人可能被認為是不禮貌的。因此,禮貌的做法是 在提交資訊末尾插入一段包含您的電子郵件和姓名(用方括號括起來)的描述,後跟一個 Signed-off-by。例如
Signed-off-by: PR Developer <[email protected]>
[[email protected]: apply code conventions]
Signed-off-by: Committer Developer <[email protected]>
不。在下述某些情況下,我們可能會接受非常小的貢獻,而無需 DCO。這適用於那些足夠小的貢獻(例如拼寫錯誤、語法錯誤、打字錯誤、格式錯誤等),這些貢獻不被您視為可獨立保護的智慧財產權(即“明顯的修復”)。此例外的目的是降低新貢獻者的門檻,使其能夠做出有益且必要的貢獻,同時維護專案和社群的完整性。
我們期待收到您更多簡化的貢獻!如果您有任何問題,請隨時在我們的問題跟蹤器中聯絡我們。