如何參與開源專案 - 細說 GitHub 上的 PR 全過程

一、概述

今天我準備和你詳細介紹如何開始參與開源專案，幫助你在 GitHub 上完成第一個 PR 的合入。

當然，除了正常的 PR 合入流程之外，我還準備詳細介紹一下如果一個 PR 提交後遇到了衝突、需要追加 commits、需要合併 commits 等等相對複雜問題該如何解決。

總的來說，本文計劃分為4個部分：

1. 談談為什麼要參與開源專案以及我為什麼要介紹如何 PR
2. 談談怎麼開始參與開源專案，也就是如何尋找合適的開源專案、如何尋找貢獻點
3. 介紹怎麼上手 PR 流程，即從 fork 到 push 全流程
4. 介紹提交了 PR 之後遇到各種常見問題如何解決

Ok, let's get started!

二、為什麼要參與開源專案

本文我不打算長篇大論“為什麼要參與開源”，詳細介紹參與開源專案的收穫，我想僅從“提升編碼能力”角度談一談“為什麼要參與開源專案”。

在面試的時候我有個習慣，如果候選人在自己的簡歷裡說到自己熟悉某一門語言，我就會習慣性問他一個問題：

你有沒有閱讀過某個開源專案的原始碼？或者更進一步，有沒有參與過某個開源社群，或者說給開源專案提過 PR？

如果答案是肯定的，比如候選人說自己讀過部分 Kubernetes 模組的原始碼，再進一步我確認他真的讀過並且讀懂了或者說真的提交過 bugfix/feature 型別的 PR，那我就不再問程式語言層面的問題了，因為我相信能看懂一個成熟的開源專案部分模組原始碼或者能夠提交 bugfix/feature 型別的 PR 已經說明了一切。

我自己在學習 Golang 的時候，大致分為兩個階段：

1. 學習基礎語法，開始寫專案，直到能夠熟練完成各種業務功能的開發；
2. 看了一些開源專案的原始碼，深感受益頗多，編碼水平再上一個臺階。

差不多也就是在看 Kubernetes 專案原始碼的時候，我深刻認識到一般的企業內部專案和彙集全世界最優秀的程式設計師智慧結晶的開源專案之間的巨大差距，也意識到學習優秀開源專案原始碼對於一個程式設計師編碼水平提升的重要性（當然，你可以說 Google 內部也存在非開源的非常優秀的程式碼，這毫無疑問，但是我想今天我們沒有必要討論特例）。

認真閱讀開源專案原始碼，你總會發現一些小瑕疵，這時候提一個 PR(Pull Request)，讓你的程式碼合入開源專案，執行在“世界每一個角落”，那是多麼有趣的事情！而成功合入第一個 PR 往往就像開啟潘多拉魔盒一樣，你會進入到另外一個世界，開始接觸到開源社群，感受開源的魅力！

三、為什麼我想介紹如何 PR

我司開源了2個專案，分別是：

1. CNCF Project DevStream

2. Apache DevLake
   

DevStream 專案和 DevLake 專案隔三差五就會有新貢獻者提交 PR 過來，但是多數貢獻者在提交第一個 PR 時往往會遇到一個或多個問題，比如產生衝突、commits 記錄過多或者混亂、commit 沒有簽名、commit message 不規範、各種 ci 流程檢查報錯等等。

在看到新貢獻者提交 PR 時，我們自然是非常開心且熱情地對他表示歡迎並且告知如何修復各種問題，但是隨著貢獻者的增多，我們的開源社群幾乎每天都需要回答一個問題：“如何正確地提交一個 PR”。可能此時你會開始懷疑我們是不是沒有提供相應的文件？其實不然，我們有詳細的文件，但是人總是有惰性的，多數的新貢獻者並沒有足夠的意願去仔細看翻看文件然後再提交 PR，甚至很多新貢獻者由於剛開始接觸開源專案，對於專案結構和文件組織結構比較陌生，甚至不會想到有這些文件的存在，總之各種各樣的理由讓多數的新貢獻者會選擇“先提了 PR再說”。

那麼今天我想嘗試徹底講明白“如何正確地提交一個 PR”，嘗試細說 GitHub 上的 PR 全過程，以及這裡面可能會遇到的各種困難和解決辦法。一方面希望對第一次參與開源專案的新人有所幫助，另一方面希望能夠進一步降低 DevStream 社群和 DevLake 社群的參與門檻。

四、我想參與開源專案，怎麼開始？

不管你為什麼決定開始參與開源專案，不管出發點是出於學習、興趣、成就感等等，還是為了讓某個自己需要的特性合入某個開源專案，總之今天你下定決心，要給某個開源專案提交一個 PR 了，好，我們開始吧！

4.1、尋找一個合適的開源專案

如果你已經決定參與某個開源社群了，那麼請直接跳過本小節。

如果你就只是想開始參與開源，暫時還不知道該參與哪個社群，那麼我有幾個小建議：

1. 不要從特別成熟的專案開始。比如現在去參與 Kubernetes 社群，一方面由於貢獻者太多，很難搶到一個入門級的 issue 來開始第一個 PR；另外一方面也由於貢獻者太多，你的聲音會被淹沒，社群維護者並不在意多你一個或者少你一個（當然可能沒有人會承認，但是你不得不信），如果你提個 PR 都遇到了各種問題還不能自己獨立解決，那麼很可能你的 PR 會直接超時關閉，沒有人在意你是不是有一個好的參與體驗；
2. 不要從特別小的專案開始。這就不需要我解釋了吧？很早期的開源專案可能面臨著非常多的問題，比如程式碼不規範、協作流程不規範、重構頻繁且不是 issue 驅動的，讓外部參與者無所適從……
3. 選擇知名開源軟體基金會的孵化專案，這類專案一方面不是特別成熟，所以對新貢獻者友好；另一方面也不會特別不成熟，不至於給人很差的參與體驗，比如 Apache 基金會、Linux 基金會、CNCF 等。

比如可以從這些地方尋找自己感興趣的開源專案：

• CNCF 沙箱專案
• CNCF 孵化專案(列表包括畢業專案)
• Apache 專案(孵化期專案名字中帶 Incubating)

當然，你也可以直接選擇從 CNCF 沙箱專案 DevStream 或者 Apache 孵化專案 Apache DevLake，以此敲開開源世界的大門。

4.2、尋找貢獻點

開源專案的參與方式很多，最典型的方式是提交一個特性開發或者 bug 修復相關的 PR，但是其實文件完善、測試用例完善、bug 反饋等等也都是非常有價值的貢獻。不過本文還是從需要提 PR 的貢獻點開始上手，以 DevStream 專案為例（其他專案也一樣），在專案 GitHub 程式碼庫首頁都會有一個 Issues 入口，這裡會記錄專案目前已知的 bug、proposal(可以理解成新需求)、計劃補充的文件、亟需完善的 UT 等等，如下圖：

在 Issues 裡我們一般可以找到一個“good first issue”標籤標記的 issues，點選這個標籤可以進一步直接篩選出所有的 good first issues，這是社群專門留給新貢獻者的相對簡單的入門級 issues：

沒錯，從這裡開始，瀏覽一下這些 good first issues，看下有沒有你感興趣的而且還沒被分配的 issue，然後在下面留言，等待專案管理員分配任務後就可以開始編碼了，就像這樣：

如圖所示，如果一個 issue 還沒有被認領，這時候你上去留個言，等待管理員會將這個任務分配給你，接著你就可以開始開發了。

五、我要提交 PR，怎麼上手？

一般開源專案程式碼庫根目錄都會有一個 CONTRIBUTING.md 或者其他類似名字的文件來介紹如何開始貢獻，像這樣：

在 DevStream 的 Contributing 文件裡我們放了一個 Development Workflow，其實就是 PR 工作流的介紹，不過今天，我要更詳細地聊聊 PR 工作流。

5.1、第一步：Fork 專案倉庫

GitHub 上的專案都有一個 Fork 按鈕，我們需要先將開源專案 fork 到自己的賬號下，以 DevStream 為例：

點一下 Fork 按鈕，然後回到自己賬號下，可以找到 fork 到的專案了：

這個專案在你自己的賬號下，也就意味著你有任意修改的許可權了。我們後面要做的事情，就是將程式碼變更提到自己 fork 出來的程式碼庫裡，然後再通過 Pull Request 的方式將 commits 合入上游專案。

5.2、第二步：克隆專案倉庫到本地

對於任意一個開源專案，流程幾乎都是一樣的。我直接寫了一些命令，大家可以複製貼上直接執行。當然，命令裡的一些變數還是需要根據你自己的實際需求修改，比如對於 DevStream 專案，我們可以先這樣配置幾個環境變數：

• 環境變數

export WORKING_PATH="~/gocode"
export USER="daniel-hutao"
export PROJECT="devstream"
export ORG="devstream-io"

同理對於 DevLake，這裡的命令就變成了這樣：

export WORKING_PATH="~/gocode"
export USER="daniel-hutao"
export PROJECT="incubator-devlake"
export ORG="apache"

記得 USER 改成你的 GitHub 使用者名稱，WORKING_PATH 當然也可以靈活配置，你想把程式碼放到哪裡，就寫對應路徑。

接著就是幾行通用的命令來完成 clone 等操作了：

• clone 等

mkdir -p ${WORKING_PATH}
cd ${WORKING_PATH}
# You can also use the url: git@github.com:${USER}/${PROJECT}.git
# if your ssh configuration is proper
git clone https://github.com/${USER}/${PROJECT}.git
cd ${PROJECT}

git remote add upstream https://github.com/${ORG}/${PROJECT}.git
# Never push to upstream locally
git remote set-url --push upstream no_push

如果你配置好了 ssh 方式來 clone 程式碼，當然，git clone 命令用的 url 可以改成git@github.com:${USER}/${PROJECT}.git。

完成這一步後，我們在本地看到的 remote 資訊應該是這樣的：

• git remote -v

origin    git@github.com:daniel-hutao/devstream.git (fetch)
origin    git@github.com:daniel-hutao/devstream.git (push)
upstream    https://github.com/devstream-io/devstream (fetch)
upstream    no_push (push)

記住囉，你本地的程式碼變更永遠只提交到 origin，然後通過 origin 提交 Pull Request 到 upstream。

5.3、第三步：更新本地分支程式碼

如果你剛剛完成 fork 和 clone 操作，那麼你本地的程式碼肯定是新的。但是“剛剛”只存在一次，接著每一次準備開始寫程式碼之前，你都需要確認本地分支的程式碼是新的，因為基於老程式碼開發你會陷入無限的衝突困境之中。

• 更新本地 main 分支程式碼：

git fetch upstream
git checkout main
git rebase upstream/main

當然，我不建議你直接在 main 分支寫程式碼，雖然你的第一個 PR 從 main 提交完全沒有問題，但是如果你需要同時提交2個 PR 呢？總之鼓勵新增一個 feat-xxx 或者 fix-xxx 等更可讀的分支來完成開發工作。

• 建立分支

git checkout -b feat-xxx

這樣，我們就得到了一個和上游 main 分支程式碼一樣的特性分支 feat-xxx 了，接著可以開始愉快地寫程式碼啦！

5.4、第四步：寫程式碼

沒啥好說的，寫就是了，寫！

5.5、第五步：Commit 和 Push

• 通用的流程：

git add <file>
git commit -s -m "some description here"
git push origin feat-xxx

當然，這裡大家需要理解這幾個命令和引數的含義，靈活調整。比如你也可以用git add --all完成 add 步驟，在 push 的時候也可以加-f引數，用來強制覆蓋遠端分支（假如已經存在，但是 commits 記錄不合你意）。但是請記得git commit的-s引數一定要加哦！

如果你習慣用 IDE 來 commit，當然也沒有任何問題，像這樣：

這裡要注意 commit message 的規範，可能每個開源專案的要求不盡相同，比如 DevStream 的規範是類似這樣的格式：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

舉幾個例子：

• feat: some description here
• docs: some description here
• fix: some description here
• fix(core): some description here
• chore: some description here
• ...

commit 和 push 兩個步驟可以在 IDE 裡一步到位，也可以分開，我習慣分開操作，給自己多一些餘地。另外，我更習慣命令列操作：

• git push origin feat-1

Counting objects: 80, done.
Delta compression using up to 10 threads.
Compressing objects: 100% (74/74), done.
Writing objects: 100% (80/80), 13.78 KiB | 4.59 MiB/s, done.
Total 80 (delta 55), reused 0 (delta 0)
remote: Resolving deltas: 100% (55/55), completed with 31 local objects.
remote: 
remote: Create a pull request for 'feat-1' on GitHub by visiting:
remote:      https://github.com/daniel-hutao/devstream/pull/new/feat-1
remote: 
To github.com:daniel-hutao/devstream.git
 * [new branch]      feat-1 -> feat-1

到這裡，本地 commits 就推送到遠端了。

5.6、第六步：開一個 PR

在完成 push 操作後，我們開啟 GitHub，可以看到一個黃色的提示框，告訴我們可以開一個 Pull Request 了：

如果你沒有看到這個框，也可以直接切換到 feat-1 分支，然後點選下方的“Contribute”按鈕來開啟一個 PR，或者直接點 Issues 邊上的 Pull requests 進入對應頁面。

• Pull Request 格式預設是這樣的：

這裡我們需要填寫一個合適的標題（預設和 commit message 一樣），然後按照模板填寫 PR 描述。PR 模板其實在每個開源專案裡都不太一樣，我們需要仔細閱讀上面的內容，避免犯低階錯誤。

比如 DevStream 的模板裡目前分為4個部分：

1. Pre-Checklist：這裡列了3個前置檢查項，提醒 PR 提交者要先閱讀 Contributing 文件，然後程式碼要有完善的註釋或者文件，儘可能新增測試用例等；
2. Description：這裡填寫的是 PR 的描述資訊，也就是介紹你的 PR 內容的，你可以在這裡描述這個 PR 解決了什麼問題等；
3. Related Issues：記得嗎？我們在開始寫程式碼之前其實是需要認領 issue 的，這裡要填寫的也就是對應 issue 的 id，假如你領的 issue 連結是 https://github.com/devstream-...，並且這個 issue 通過你這個 PR 的修改後就完成了，可以關閉了，這時候可以在 Related Issues 下面寫“close #796”；
4. New Behavior：程式碼修改後絕大多數情況下是需要進行測試的，這時候我們可以在這裡貼上測試結果截圖，這樣 reviewers 就能夠知道你的程式碼已經通過測試，功能符合預期，這樣可以減少 review 工作量，快速合入。

這個模板並不複雜，我們直接對著填寫就行。

• 比如：

然後點選右下角“Create pull request”就完成了一個 PR 的建立了。不過我這裡不能去點這個按鈕，我用來演示的修改內容沒有意義，不能合入上游程式碼庫。不過我還是想給你看下 PR 建立出來後的效果，我們以 pr655 為例吧：

這是上個月我提的一個 PR，基本和模板格式一致。除了模板的內容，可能你已經注意到這裡多了一個 Test 小節，沒錯，模板不是死的，模板只是為了降低溝通成本，你完全可以適當調整，只要結果是“往更清晰的方向走”的。我這裡通過 Test 部分新增了本地詳細測試結果記錄，告訴 reviewers 我已經在本地充分測試了，請放心合入。

提交了 PR 之後，我們就可以在 PR 列表裡找到自己的 PR 了，這時候還需要注意 ci 檢查是不是全部能夠通過，假如失敗了，需要及時修復。以 DevStream 為例，ci 檢查項大致如下：

5.7、第七步：PR 合入

如果你的 PR 很完美，毫無爭議，那麼過不了太長時間，專案管理員會直接合入你的 PR，那麼你這個 PR 的生命週期也就到此結束了。

但是，沒錯，這裡有個“但是”，但是往往第一次 PR 不會那麼順利，我們接下來就詳細介紹一下可能經常遇到的一些問題和對應的解決辦法。

六、我提交了一個 PR，然後遇到了問題 A,B,C,D,E,F,G,...?

多數情況下，提交一個 PR 後是不會被馬上合入的，reviewers 可能會提出各種修改意見，或者我們的 PR 本身存在一些規範性問題，或者 ci 檢查就直接報錯了，怎麼解決呢？繼續往下看吧。

6.1、Reviewers 提了一些修改意見，我如何更新 PR？

很多時候，我們提交了一個 PR 後，還需要繼續追加 commit，比如提交後發現程式碼還有點問題，想再改改，或者 reviewers 提了一些修改意見，我們需要更新程式碼。

一般我們遵守一個約定：在 review 開始之前，更新程式碼儘量不引入新的 commits 記錄，也就是能合併就合併，保證 commits 記錄清晰且有意義；在 review 開始之後，針對 reviewers 的修改意見所產生的新 commit，可以不向前合併，這樣能夠讓二次 review 工作更有針對性。

不過不同社群要求不一樣，可能有的開源專案會要求一個 PR 裡只能包含一個 commit，大家根據實際場景靈活判斷即可。

說回如何更新 PR，我們只需要在本地繼續修改程式碼，然後通過和第一個 commit 一樣的步驟，執行這幾個命令：

git add <file>
git commit -s -m "some description here"
git push origin feat-xxx

這時候別看 push 的是 origin 的 feat-xxx 分支，其實 GitHub 會幫你把新增的 commits 全部追加到一個未合入 PR 裡去。沒錯，你只管不斷 push，PR 會自動更新。

至於如何合併 commits，我們下一小節具體介紹。

6.2、Commits 太多或者記錄混亂，如何合併 Commits？

很多情況下我們需要去合併 commits，比如你的第一個 commit 裡改了100行程式碼，然後發現少改了1行，這時候又提交了一個 commit，那麼第二個 commit 就太“沒意思”了，我們需要合併一下。

6.2.1、Git 命令列方式合併 Commits

比如我這裡有2個同名的 commits，第二個 commit 其實只改了一個標點：

這時候我們可以通過 rebase 命令來完成2個 commits 的合併：

git rebase -i HEAD~2

執行這個命令會進入一個編輯頁面，預設是 vim 編輯模式，內容大致如下：

pick 3114c0f docs: just for test
pick 9b7d63b docs: just for test

# Rebase d640931..9b7d63b onto d640931 (2 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.

我們需要把第二個 pick 改成 s，然後儲存退出(vim 的 wq 命令)：

pick 3114c0f docs: just for test
s 9b7d63b docs: just for test

接著會進入第二個編輯頁面：

# This is a combination of 2 commits.
# This is the 1st commit message:

docs: just for test

Signed-off-by: Daniel Hu <tao.hu@merico.dev>

# This is the commit message #2:

docs: just for test

Signed-off-by: Daniel Hu <tao.hu@merico.dev>

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# ...

這裡是用來編輯合併後的 commit message 的，我們直接刪掉多餘部分，只保留這樣幾行：

docs: just for test

Signed-off-by: Daniel Hu <tao.hu@merico.dev>

接著同樣是 vim 的儲存退出操作，這時候可以看到日誌：

[detached HEAD 80f5e57] docs: just for test
 Date: Wed Jul 6 10:28:37 2022 +0800
 1 file changed, 2 insertions(+)
Successfully rebased and updated refs/heads/feat-1.

這時候可以通過git log命令檢視下 commits 記錄是不是符合預期：

好，我們在本地確認 commits 已經完成合並，這時候就可以繼續推送到遠端，讓 PR 也更新掉：

git push -f origin feat-xxx

這裡需要有一個-f引數來強制更新，合併了 commits 本質也是一種衝突，需要衝掉遠端舊的 commits 記錄。

6.2.2 IDE 裡合併 Commits

圖形化方式當然也可以實現 Commits 的合併。

• 截圖走起
  

1. 點選右下角的 Git
2. 選擇想要合併的 commits
3. 右鍵，然後點選 Squash Commits，記得嘴裡默唸一句：走你！

接著就可以看到這個頁面了：

這是圖形化方式修改 commit message 的頁面，行吧，改成你喜歡的樣子，然後點選右下角的 OK 按鈕，事情就算結束了。

看，2個 commits，它們“融合”了，變成了一個“改頭換面”的新 commit 了。

6.3、PR 產生了衝突，如何解決？

衝突可以線上解決，也可能本地解決，我們逐個來看。

6.3.1、線上解決衝突

我們要儘可能避免衝突，養成每次寫程式碼前更新原生程式碼的習慣。不過，衝突不可能完全避免，有時候你的 PR 被阻塞了幾天，可能別人改了同一行程式碼，還搶先被合入了，這時候你的 PR 就出現衝突了，類似這樣（同樣，此刻我不能真的去上游專案構造衝突，所以下面用於演示的衝突在我在自己的 repo 裡）：

每次看到這個頁面都會讓人覺得心頭一緊。我們點選“Resolve conflicts”按鈕，就可以看到具體衝突的內容了：

可以看到具體衝突的行了，接下來要做的就是解決衝突。我們需要刪掉所有的 <<<<<<<、>>>>>>> 和 ======= 標記，只保留最終想要的內容，如下：

接著點選右上角的“Mark as Resolved”：

最後點選“Commit merge”：

這樣就完成衝突解決了，可以看到產生了一個新的 commit：

到這裡，衝突就解決掉了。

6.3.2、本地解決衝突

更多時候，我們需要在本地解決衝突，尤其是衝突太多，太複雜的時候。

同樣，我們構造一個衝突，這次嘗試在本地解決衝突。

• 先線上看一下衝突的內容：

• 接著我們在本地執行：

# 先切回到 main 分支
git checkout main
# 拉取上游程式碼（實際場景肯定是和上游衝突，我們這裡的演示環境其實是 origin）
git fetch upstream
# 更新本地 main（這裡也可以用 rebase，但是 reset 不管有沒有衝突總是會成功）
git reset --hard upstream/main

到這裡，本地 main 分支就和遠端(或者上游) main 分支程式碼完全一致了，然後我們要做的是將 main 分支的程式碼合入自己的特性分支，同時解決衝突。

git checkout feat-1
git rebase main

• 這時候會看到這樣的日誌：

First, rewinding head to replay your work on top of it...
Applying: docs: conflict test 1
Using index info to reconstruct a base tree...
M       README.md
Falling back to patching base and 3-way merge...
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
error: Failed to merge in the changes.
Patch failed at 0001 docs: conflict test 1
The copy of the patch that failed is found in: .git/rebase-apply/patch

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

我們需要解決衝突，直接開啟 README.md，找到衝突的地方，直接修改。這裡的改法和上一小節介紹的線上解決衝突沒有任何區別，我就不贅述了。

程式碼裡同樣只保留最終內容，然後繼續 git 命令走起來：

可能此時你並不放心，那就通過git log命令看一下 commits 歷史記錄吧：

這裡的“conflict test 2”是我提交到 main 分支的記錄，可以看到這個時間比“conflict test 1”還要晚了一些，但是它先合入了。我們在 rebase 操作後，這個記錄在前，我們特性分支的“conflict test 1”在後，看起來很和諧，我們繼續將這個變更推送到遠端，這個命令已經出現很多次了：

git push -f origin feat-xxx

這時候我們再回到 GitHub 看 PR 的話，可以發現衝突已經解決了，並且沒有產生多餘的 commit 記錄，也就是說這個 PR 的 commit 記錄非常乾淨，好似衝突從來沒有出現過：

至於什麼時候可以線上解決衝突，什麼時候適合本地解決衝突，就看大家如何看待“需不需要保留解決衝突的記錄”了，不同社群的理解不一樣，可能特別成熟的開源社群會希望使用本地解決衝突方式，因為線上解決衝突產生的這條 merge 記錄其實“沒營養”。至於 DevStream 社群和 DevLake 社群，我們推薦使用後一種，但是不做強制要求。

6.4、CI 檢查不過：commit message 相關問題如何修復？

前面我們提到過 commit message 的規範，但是第一次提交 PR 的時候還是很容易出錯，比如feat: xxx其實能通過 ci 檢查，但是feat: Xxx就不行了。假設現在我們不小心提交了一個 PR，但是裡面 commit 的 message 不規範，這時候怎麼修改呢？

• 太簡單了，直接執行：

git commit --amend

這條命令執行後就能進入編輯頁面，隨意更新 commit message 了。改完之後，繼續 push：

git push -f origin feat-xxx

這樣就能更新 PR 裡的 commit message 了。

6.5、CI 檢查不過：DCO(sign) 問題如何修復？

相當多的開源專案會要求所有合入的 commits 都包含一行類似這樣的記錄：

Daniel Hu <tao.hu@merico.dev>

所以 commit message 看起來會像這樣：

feat: some description here
    
Signed-off-by: Daniel Hu <tao.hu@merico.dev>

這行資訊相當於是對應 commit 的作者簽名。要新增這樣一行簽名當然很簡單，我們直接在git commit命令後面加一個-s引數就可以了，比如git commit -s -m "some description here"提交的 commit 就會帶上你的簽名。

但是如果如果你第一次提交的 PR 裡忘記了在 commits 中新增 Signed-off-by 呢？這時候，如果對應開源專案配置了 DCO 檢查，那麼你的 PR 就會在 ci 檢查中被“揪出來”沒有正確簽名。

同樣先構造一個沒有加簽名的 commit：

我不能直接推到 DevStream 專案程式碼庫裡演示如何讓 DCO 報錯，但是如果提 PR，看到的效果是這樣的：

我們看下如何解決：

• git commit --amend -s

這樣一個簡單的命令，就能直接在最近一個 commit 里加上 Signed-off-by 資訊。執行這行命令後會直接進入 commit message 編輯頁面，預設如下圖：

docs: dco test

Signed-off-by: Daniel Hu <tao.hu@merico.dev>

這時候我們可以同時修改 commit message，如果不需要，那就直接儲存退出好了，簽名資訊是會自動加上的。

完成簽名後呢？當然是來一個強制 push 了：

git push -f origin feat-xxx

這樣，你 PR 中的 DCO 報錯就自然修復了。

七、最後

一個不小心這篇文章寫的有點長了。行，打完收工！

• 歡迎到我的個人網站或者微信公眾號“胡說雲原生”瀏覽更多我的文章；
• 歡迎關注DevStream 社群，和我一起玩開源；
• 歡迎到DevStream 官方部落格瀏覽更多 DevStream 團隊釋出的文章。