手把手教你在 GitHub 上優雅的提交 PR

一、概述

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

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

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

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

Ok, let's get started!

二、爲什麼要參與開源項目

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

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

你有沒有閱讀過某個開源項目的源碼？或者更進一步，有沒有參與過某個開源社區，或者說給開源項目提過 PR？

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

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

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

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

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

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

我司開源了 2 個項目，分別是：

CNCF Project DevStream[1]

CNCF Project DevStream

Apache DevLake[2]

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

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

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

四、我想參與開源項目，怎麼開始？

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

4.1、尋找一個合適的開源項目

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

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

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

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

CNCF 沙箱項目 [3]
CNCF 孵化項目 (列表包括畢業項目)[4]
Apache 項目 (孵化期項目名字中帶 Incubating)[5]

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

4.2、尋找貢獻點

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

DevStream Issues

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

DevStream Good First Issues

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

Claim an Issue in DevStream

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

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

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

DevStream Contributing

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

5.1、第一步：Fork 項目倉庫

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

Fork DevStream

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

DevStream 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，當然也沒有任何問題，像這樣：

DevStream Commit with Goland

這裏要注意 commit message 的規範，可能每個開源項目的要求不盡相同，比如 DevStream 的規範 [11] 是類似這樣的格式：

<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 了：

Compare & pull request

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

Pull Request 格式默認是這樣的：

DevStream Pull Request

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

比如 DevStream 的模板裏目前分爲 4 個部分：

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

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

比如：

DevStream Pull Request Template

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

DevStream Pull Request 655

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

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

DevStream CI Checks

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 其實只改了一個標點：

Commits to be Merged

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

git rebase -i HEAD~2

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

pick 3114c0f docs: just fortest
pick 9b7d63b docs: just fortest

# 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 fortest
s 9b7d63b docs: just fortest

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

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

docs: just fortest

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

# This is the commit message #2:

docs: just fortest

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 fortest

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

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

[detached HEAD 80f5e57] docs: just fortest
 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 記錄是不是符合預期：

Rebased

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

git push -f origin feat-xxx

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

6.2.2 IDE 裏合併 Commits

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

截圖走起

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

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

Squash with Goland

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

Squash with Goland

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

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

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

6.3.1、在線解決衝突

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

Conflict Happened

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

Conflict File

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

Conflict Resolved

接着點擊右上角的 “Mark as Resolved”：

Mark as resolved

最後點擊 “Commit merge”：

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

Conflict Resolved

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

6.3.2、本地解決衝突

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

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

先在線看一下衝突的內容：

Conflict Happened

接着我們在本地執行：

# 先切回到 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 命令走起來：

Conflict Resolved

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

Commits History

這裏的 “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 檢查 [13]，那麼你的 PR 就會在 ci 檢查中被 “揪出來” 沒有正確簽名。

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

請添加圖片描述

Commit Without Sign

我不能直接推到 DevStream 項目代碼庫裏演示如何讓 DCO 報錯，但是如果提 PR，看到的效果是這樣的：

Commit With DCO Error

我們看下如何解決：

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 報錯就自然修復了。

七、最後

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

歡迎到我的個人網站 [14] 或者微信公衆號 “胡說雲原生” 瀏覽更多我的文章；
歡迎關注 DevStream 社區 [15]，和我一起玩開源；
歡迎到 DevStream 官方博客 [16] 瀏覽更多 DevStream 團隊發佈的文章。

本文外鏈

[1]

CNCF Project DevStream: https://github.com/devstream-io/devstream

[2]

Apache DevLake: https://github.com/apache/incubator-devlake

[3]

CNCF 沙箱項目: https://www.cncf.io/sandbox-projects/

[4]

CNCF 孵化項目 (列表包括畢業項目): https://www.cncf.io/projects/

[5]

Apache 項目 (孵化期項目名字中帶 Incubating): https://projects.apache.org/projects.html

[6]

DevStream: https://www.cncf.io/projects/devstream/

[7]

Apache DevLake: https://projects.apache.org/project.html?incubator-devlake

[8]

Issues 入口: https://github.com/devstream-io/devstream/issues

[9]

DevStream 的 Contributing: https://github.com/devstream-io/devstream/blob/main/CONTRIBUTING.md

[10]

Development Workflow: https://github.com/devstream-io/devstream/blob/main/docs/development/development-workflow.md

[11]

規範: https://github.com/devstream-io/devstream/blob/main/docs/development/commit-messages.md

[12]

pr655: https://github.com/devstream-io/devstream/pull/655

[13]

DCO 檢查: https://wiki.linuxfoundation.org/dco

[14]

我的個人網站: https://www.danielhu.cn

[15]

DevStream 社區: https://github.com/devstream-io

[16]

DevStream 官方博客: https://blog.devstream.io

來源：胡說雲原生

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/e83QM7-1TV0bNvyHsAcfng

一、概述

二、爲什麼要參與開源項目

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

四、我想參與開源項目，怎麼開始？

4.1、尋找一個合適的開源項目

4.2、尋找貢獻點

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

5.1、第一步：Fork 項目倉庫

5.2、第二步：克隆項目倉庫到本地

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

5.4、第四步：寫代碼

5.5、第五步：Commit 和 Push

5.6、第六步：開一個 PR

5.7、第七步：PR 合入

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

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

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

6.2.1、Git 命令行方式合併 Commits

6.2.2 IDE 裏合併 Commits

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

6.3.1、在線解決衝突

6.3.2、本地解決衝突

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

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

七、最後

猜你喜歡