使用 git pull request 為開源項目做出貢獻的工作流程是什么？ （例如通過 Github）

Question

我對我如何做到這一點有一個全面的逐步描述，我想在這里分享它，以便開發人員可以從中受益（我會回答我自己的問題）。

Answer 1

由於對開源項目所做的更改必須經過同行評審，因此通常會看到依賴於 git pull 請求的工作流。 不允許從直接克隆的 repos 中提取請求（您需要自己的 fork）。 因此，我遵循以下步驟來維護一個健康的分叉並定期為開源做出貢獻：

注意：步驟 1、2 和 3 僅在單個開發機器上為每個項目執行一次以設置所有內容。

注意 2：如果您將貢獻的開源項目不使用 master 作為默認工作分支，您必須將下面步驟 4) 和 7) 的命令中對“master”的所有引用替換為名稱那個分支。

1）確保您在項目的“分支”上本地工作，而不是在指向項目作為源的克隆存儲庫上工作。 要分叉 Github 項目，請訪問https://github.com/entity/project ，單擊“分叉”並為分叉選擇合適的 GitHub 帳戶，例如。 您的個人 Github 帳戶。 請注意，您的分叉項目“起源”將不再是原始項目存儲庫，而是您自己在 Github 上的分叉。 如果您要分叉一個私人項目，請注意隱私，因為您可能不希望您的分叉公開。

2)將您自己的項目 fork 克隆到您的開發機器中，然后 cd 進入該目錄。

git clone git@github.com:yourgithubuser/project.git

3）將原始項目存儲庫添加為您的分叉項目中的上游存儲庫。

git remote add upstream git@github.com:entity/project.git

原來的主要項目回購現在是“上游”，但不是“起源”

現在是您在處理分叉項目時將重復的工作循環：

4)在開始工作之前，請務必確保您的分叉倉庫的主分支與原始項目倉庫的主分支同步：

git checkout master
git fetch upstream
git merge upstream/master
git push origin master

5)在您的項目分支中為您想要貢獻的特定修復創建一個新分支（在錯誤修復、跟蹤器問題、文檔部分等之后命名）並切換到它。

git checkout -b myfixes

這會自動創建分支並切換到它。 確保分支不存在。 您可能還想擺脫已經合並到文檔中的舊修復分支（否則您的項目中將有大量無用的分支）。 您可以通過發出git branch查看本地git branch ，如果在該列表中您找到已與上游項目合並的分支，則可以執行以下操作：

git branch -D myoldfixes
git push origin --delete myoldfixes

重要提示：如果您已經在另一台機器上的分支上工作，並希望在新機器上繼續該工作，您需要在新機器上重做步驟 2、3 和 4，並在步驟 5 中而不是執行git checkout -b myfixes你應該做git checkout myfixes （刪除 -b）。 否則，您最終可能會出現一個不好的“分離頭”狀態（一種匿名分支）

6）在該分支上工作（例如myfixes）並提交您的更改：

git commit -a -m "My fixes"

（或者，您可以在不使用 -a 的情況下暫存特定文件並提交。您可以根據需要多次提交，但不要在分支中留下未提交的更改）

7）當您進行修復時，原始上游項目 repo 可能已經更改（由於其他貢獻者正在處理它）。 因此，首先您必須從上游目標分支重新定位當前分支（myfixes）。 換句話說，您需要在上游 repo master 分支的最新工作之上重播您的修復，以確保您的提交仍然與上游中的最新提交兼容。 這將導致我們想要的拉取請求的快進合並：

git checkout myfixes
git pull --rebase upstream master

注意 3 ：這可能會導致沖突，但這是正常的，修復它們是過程的一部分（這種情況在非常活躍的項目中更常見）

注意 4 ：如果您在分支中有許多提交並且您是一個體貼的人，您可能希望將您的提交壓縮為一個，以使原始項目的維護者受益

8)修復上一步的沖突（如果有）后，您已將修復應用到最新版本的上游 master 之上。 由於拉取請求是從您在 Github 上的分叉存儲庫發起的，因此您也希望保持同步：

git checkout myfixes
git push origin myfixes -f

9）最后，你可以去Github https://github.com/entity/project （原來的項目不是你的fork），點擊“Pull Request”。 確保您選擇上游倉庫“master”作為目標分支，並將您的分叉倉庫“myfixes”作為源分支（在拉取請求被接受后，該分支將自動為您刪除）

享受！

Answer 2

6a)提交的主題和提交消息的格式也很關鍵。

提交主題

提交主題應僅涵蓋一項邏輯更改。 例如，如果您要向某人描述更改（例如在提交消息中，見下文），您不應該使用“和”一詞來描述主題，例如。 不是“修復錯誤 123 並更新配置默認值。” 這些應該是兩個單獨的提交。

如果您在工作樹中有一堆單獨的問題已解決但未提交，那么交互式添加是一個很好的工具。 讓你的手指記住這批命令，然后按照說明進行操作：

git add -i
5<CR>
*<CR>

您可以對其他選項更感興趣，但這就是說“向我展示我工作樹中的每一個變化，讓我選擇要上演的內容。”

然后，像往常一樣：

git ci

提交消息

您希望在標題中簡潔明了，以便人們瀏覽歷史，同時還為未來（包括六個月后的您自己！）深入研究涉及您的更改的問題提供良好的正文細節。

我最喜歡的編寫好提交消息的指南是Erlang/OTP wiki page on good commit messages ，我要補充一點，使用以下格式不會出錯：

Short (<50 chars) present-tense summary of changes

Previously, <a couple sentences clearly describing the previous behavior
and the resulting customer issue>. 

This commit <a sentence or two clearly describing the code change, and the
resulting expected behavior>.