為項目做貢獻

• 提交準則
• 私人小團隊
• 私人管理團隊
• 分叉公共項目
• 通過電子郵件公開項目
• 總結

描述如何為項目做出貢獻的主要困難是如何做到這一點的眾多變化。因為 Git 非常靈活，人們可以而且確實以多種方式一起工作，而且描述你應該如何貢獻是有問題的——每個項目都有點不同。涉及的一些變量包括活動參與者計數、所選工作流、提交訪問權限以及可能的外部貢獻者方法。

第一個變量是活動貢獻者計數 — 有多少用戶正在為此項目積極貢獻代碼，以及多久貢獻一次？在許多情況下，您將有兩到三個開發人員，每天提交幾個，或者對于有些休眠的項目，可能更少。對于較大的公司或項目，開發人員的數量可能達到數千，每天有數百或數千個提交。這很重要，因為隨著越來越多的開發人員，您在確保代碼干凈地應用或可以輕松合并方面會遇到更多問題。您提交的更改可能會因在您工作時或等待批準或應用時合并的工作而過時或嚴重中斷。如何使代碼始終保持最新狀態且提交有效？

下一個變量是用于項目的工作流。它是否是集中式的，每個開發人員對主代碼線具有平等的寫入權限？項目是否有維護者或集成經理檢查所有補丁？所有補丁都經過同行評審和批準嗎？您是否參與了該過程？中尉制度是否到位，您是否必須首先向他們提交您的工作？

下一個變量是提交訪問權限。如果您具有項目的寫入權限，則為項目做出貢獻所需的工作流與沒有寫入權限時的工作流有很大不同。如果您沒有寫入權限，項目如何更愿意接受貢獻的工作？它甚至有政策嗎？您一次貢獻了多少工作？您多久貢獻一次？

所有這些問題都會影響您如何有效地為項目做出貢獻，以及哪些工作流程是首選的或可用的。我們將在一系列用例中介紹其中每個方面，從簡單到更復雜;您應該能夠從這些示例中構建實踐中所需的特定工作流。

提交準則

在我們開始查看特定用例之前，下面是有關提交消息的快速說明。擁有一個很好的創建提交并堅持下去的指南，使得使用Git和與他人協作變得更加容易。Git 項目提供了一個文檔，其中列出了許多創建提交以提交補丁的良好提示 — 您可以在文件的 Git 源代碼中讀取它。Documentation/SubmittingPatches

首先，您的提交不應包含任何空格錯誤。Git 提供了一種簡單的方法來檢查此問題 — 在提交之前，運行 ，它可以識別可能的空格錯誤并為您列出它們。git diff --check

如果在提交之前運行該命令，則可以判斷是否要提交可能惹惱其他開發人員的空格問題。

接下來，嘗試使每個提交在邏輯上都是單獨的變更集。如果可以的話，試著讓你的更改易于消化——不要在五個不同的問題上為整個周末編寫代碼，然后在周一將它們全部作為一個大規模提交提交。即使您在周末不提交，也可以使用星期一的暫存區域將工作拆分為每個問題至少一個提交，每個提交都有一條有用的消息。如果某些更改修改了同一文件，請嘗試使用 來暫存文件（在交互式暫存中詳細介紹）。無論您執行一次提交還是五次提交，分支頂部的項目快照都是相同的，只要在某個時刻添加了所有更改，因此，當您的開發人員必須查看您的更改時，請嘗試使其他開發人員更容易。git add --patch

此方法還使以后需要時可以更輕松地拉出或還原其中一個變更集。重寫歷史記錄描述了許多有用的 Git 技巧，用于重寫歷史記錄和交互式暫存文件 — 在將工作發送給其他人之前，使用這些工具幫助制作干凈且易于理解的歷史記錄。

最后要記住的是提交消息。養成創建高質量提交消息的習慣，使得使用和協作 Git 變得更加容易。作為一般規則，您的郵件應以不超過約 50 個字符的一行開頭，并簡明扼要地描述變更集，后跟一個空行，后跟更詳細的說明。Git 項目要求更詳細的解釋包括你對更改的動機，并將其實現與以前的行為進行對比 — 這是一個很好的遵循準則。在命令式中寫下你的提交消息：“修復錯誤”，而不是“修復錯誤”或“修復錯誤”。

私人小團隊

您可能會遇到的最簡單的設置是一個包含一兩個其他開發人員的私有項目。在這種情況下，“私有”意味著閉源——外部世界無法訪問。您和其他開發人員都具有對存儲庫的推送訪問權限。

在此環境中，您可以遵循類似于使用 Subversion 或其他集中式系統時可能執行的操作的工作流。您仍然可以獲得離線提交和更簡單的分支和合并等優點，但工作流程可能非常相似;主要區別在于合并在提交時在客戶端而不是在服務器上進行。讓我們看看當兩個開發人員開始使用共享存儲庫時，它會是什么樣子。第一個開發人員 John 克隆存儲庫，進行更改，并在本地提交。在這些示例中，協議消息已被替換為，以縮短它們。…?

# John's Machine $ git clone john@githost:simplegit.git Cloning into 'simplegit'... ... $ cd simplegit/ $ vim lib/simplegit.rb $ git commit -am 'Remove invalid default value' [master 738ee87] Remove invalid default value1 files changed, 1 insertions(+), 1 deletions(-)

第二個開發人員Jessica也做了同樣的事情 —— 克隆存儲庫并提交更改：

# Jessica's Machine $ git clone jessica@githost:simplegit.git Cloning into 'simplegit'... ... $ cd simplegit/ $ vim TODO $ git commit -am 'Add reset task' [master fbff5bc] Add reset task1 files changed, 1 insertions(+), 0 deletions(-)

現在，Jessica 將她的工作推送到服務器，這工作正常：

# Jessica's Machine $ git push origin master ... To jessica@githost:simplegit.git1edee6b..fbff5bc master -> master

上面輸出的最后一行顯示了來自推送操作的有用返回消息。基本格式為 ，其中表示舊引用，表示新引用，是正在推送的本地引用的名稱，并且是正在更新的遠程引用的名稱。您將在下面的討論中看到類似的輸出，因此對含義有一個基本的想法將有助于理解存儲庫的各種狀態。有關 git-push 的文檔提供了更多詳細信息。… fromref → torefoldrefnewreffromreftoref

繼續此示例，不久之后，John 進行了一些更改，將它們提交到他的本地存儲庫，并嘗試將它們推送到同一服務器：

# John's Machine $ git push origin master To john@githost:simplegit.git! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'john@githost:simplegit.git'

在這種情況下，約翰的推動失敗了，因為杰西卡早些時候推動了她的改變。如果您習慣于 Subversion，了解這一點尤其重要，因為您會注意到這兩個開發人員沒有編輯同一個文件。盡管如果編輯了不同的文件，Subversion 會自動在服務器上執行此類合并，但對于 Git，您必須首先在本地合并提交。換句話說，John 必須首先獲取 Jessica 的上游更改，并將它們合并到他的本地存儲庫中，然后才能允許他推送。

作為第一步，約翰獲取了杰西卡的工作（這只提取了杰西卡的上游工作，它還沒有將其合并到約翰的工作中）：

$ git fetch origin ... From john@githost:simplegit+ 049d078...fbff5bc master -> origin/master

此時，John 的本地存儲庫如下所示：

現在，約翰可以將杰西卡的作品合并到他自己的本地作品中：

$ git merge origin/master Merge made by the 'recursive' strategy.TODO | 1 +1 files changed, 1 insertions(+), 0 deletions(-)

只要本地合并順利進行，John 的更新歷史記錄現在將如下所示：

在這一點上，John 可能想要測試這個新代碼，以確保 Jessica 的工作不會影響他的任何工作，只要一切看起來都沒問題，他最終可以將新的合并工作推送到服務器：

$ git push origin master ... To john@githost:simplegit.gitfbff5bc..72bbc59 master -> master

最后，John 的提交歷史記錄將如下所示：

與此同時，Jessica 創建了一個名為 的新主題分支，并對該分支進行了三次提交。她尚未獲取 John 的更改，因此她的提交歷史記錄如下所示：issue54

突然，杰西卡得知 John 已經向服務器推送了一些新工作，她想看一看，這樣她就可以從服務器中獲取她還沒有的所有新內容：

$ git fetch origin ... From jessica@githost:simplegitfbff5bc..72bbc59 master -> origin/master

這拉低了約翰在此期間推動的工作。杰西卡的歷史現在看起來像這樣：

杰西卡認為她的主題分支已經準備好了，但她想知道約翰的哪一部分工作她必須合并到她的作品中，以便她可以推動。她跑去發現：git log

$ git log --no-merges issue54..origin/master commit 738ee872852dfaa9d6634e0dea7a324040193016 Author: John Smith <xqcom> Date: Fri May 29 16:01:27 2021 -0700

Remove invalid default value
語法是一個日志過濾器，它要求 Git 僅顯示位于后一個分支（在本例中）上但不在第一個分支（在本例中）的提交。我們將在提交范圍中詳細介紹此語法。issue54…origin/masterorigin/masterissue54

從上面的輸出中，我們可以看到 John 所做的一個提交，Jessica 沒有合并到她的本地工作中。如果她合并，那就是修改她的本地工作的單一提交。origin/master

現在，Jessica 可以將她的主題工作合并到她的分支中，將 John 的工作 （） 合并到她的分支中，然后再次推送回服務器。masterorigin/mastermaster

首先（在她的主題分支上完成了所有工作之后），Jessica切換回她的分支，準備整合所有這些工作：issue54master

$ git checkout master Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

杰西卡可以合并任何一個，也可以先合并——它們都在上游，所以順序并不重要。無論她選擇哪種順序，結束快照都應該是相同的;只是歷史會有所不同。她選擇先合并分支：origin/masterissue54issue54

$ git merge issue54 Updating fbff5bc..4af4298 Fast forwardREADME | 1 +lib/simplegit.rb | 6 +++++-2 files changed, 6 insertions(+), 1 deletions(-)

沒有問題發生;正如你所看到的，這是一個簡單的快進合并。Jessica 現在通過合并 John 之前在分支中獲取的工作來完成本地合并過程：origin/master

$ git merge origin/master Auto-merging lib/simplegit.rb Merge made by the 'recursive' strategy.lib/simplegit.rb | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)

一切都干凈利落地融合在一起，杰西卡的歷史現在看起來像這樣：

現在可以通過Jessica的分支到達，所以她應該能夠成功推動（假設John在此期間沒有推動更多的變化）：origin/mastermaster

$ git push origin master ... To jessica@githost:simplegit.git72bbc59..8059c15 master -> master

每個開發人員都承諾了幾次，并成功地合并了彼此的工作。

這是最簡單的工作流程之一。您工作一段時間（通常在主題分支中），并在準備好集成時將其合并到您的分支中。當您想要共享該工作時，如果工作已更改，則可以提取并合并您的工作，最后推送到服務器上的分支。一般順序如下：mastermasterorigin/mastermaster

私人管理團隊

在下一個方案中，你將查看較大專用組中的參與者角色。您將學習如何在小組協作處理功能的環境中工作，之后這些基于團隊的貢獻將由另一方集成。

假設 John 和 Jessica 正在合作開發一個功能（稱為“featureA”），而 Jessica 和第三個開發人員 Josie 正在開發第二個功能（例如“featureB”）。在這種情況下，公司正在使用一種集成管理器工作流，其中各個組的工作僅由某些工程師集成，并且主存儲庫的分支只能由這些工程師更新。在此方案中，所有工作都在基于團隊的分支中完成，并由集成商稍后完成。master

讓我們跟隨 Jessica 的工作流程，了解她的兩個功能，在此環境中與兩個不同的開發人員并行協作。假設她已經克隆了她的存儲庫，她決定先處理。她為該功能創建了一個新分支，并在那里做了一些工作：featureA

# Jessica's Machine $ git checkout -b featureA Switched to a new branch 'featureA' $ vim lib/simplegit.rb $ git commit -am 'Add limit to log function' [featureA 3300904] Add limit to log function1 files changed, 1 insertions(+), 1 deletions(-)

此時，她需要與 John 共享她的工作，因此她將分支提交推送到服務器。Jessica 沒有推送對分支的訪問權限 - 只有集成商有 - 所以她必須推送到另一個分支才能與 John 合作：featureAmaster

$ git push -u origin featureA ... To jessica@githost:simplegit.git* [new branch] featureA -> featureA

杰西卡給約翰發了電子郵件，告訴他她已經把一些工作推到了一個名為的分支上，他現在可以看看了。在等待約翰的反饋時，杰西卡決定開始與喬茜合作。首先，她啟動了一個新的功能分支，基于服務器的分支：featureAfeatureBmaster

# Jessica's Machine $ git fetch origin $ git checkout -b featureB origin/master Switched to a new branch 'featureB'

現在，Jessica 在分支上做了幾個提交：featureB

$ vim lib/simplegit.rb $ git commit -am 'Make ls-tree function recursive' [featureB e5b0fdc] Make ls-tree function recursive1 files changed, 1 insertions(+), 1 deletions(-) $ vim lib/simplegit.rb $ git commit -am 'Add ls-files' [featureB 8512791] Add ls-files1 files changed, 5 insertions(+), 0 deletions(-)

Jessica 的存儲庫現在如下所示：

她準備推動自己的工作，但收到Josie的電子郵件，說一個具有初始“featureB”工作的分支已經作為分支推送到服務器。Jessica 需要將這些更改與她自己的更改合并，然后才能將工作推送到服務器。杰西卡首先獲取喬西的變化：featureBeegit fetch

$ git fetch origin ... From jessica@githost:simplegit* [new branch] featureBee -> origin/featureBee

假設Jessica仍在她簽出的分支中，她現在可以將Josie的工作合并到該分支中：featureBgit merge

$ git merge origin/featureBee Auto-merging lib/simplegit.rb Merge made by the 'recursive' strategy.lib/simplegit.rb | 4 ++++1 files changed, 4 insertions(+), 0 deletions(-)

在這一點上，Jessica希望將所有這些合并的“featureB”工作推送回服務器，但她不想簡單地推送自己的分支。相反，由于Josie已經開始了上游分支，Jessica希望推動該分支，她這樣做：featureBfeatureBee

$ git push -u origin featureB:featureBee ... To jessica@githost:simplegit.gitfba9af8..cd685d1 featureB -> featureBee

這稱為引用規范。請參閱 Refspec，更詳細地討論 Git refspecs 以及您可以使用它們執行的不同操作。還要注意旗幟;這是 的縮寫，它配置了分支以便以后更容易地推拉。-u–set-upstream

突然，杰西卡收到了約翰的電子郵件，約翰告訴她，他已經對他們正在合作的分支進行了一些更改，他要求杰西卡看看它們。同樣，Jessica運行了一個簡單的程序，從服務器獲取所有新內容，當然包括（當然）John的最新作品：featureAgit fetch

$ git fetch origin ... From jessica@githost:simplegit3300904..aad881d featureA -> origin/featureA

Jessica 可以通過將新獲取的分支的內容與同一分支的本地副本進行比較來顯示 John 新工作的日志：featureA

$ git log featureA..origin/featureA commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6 Author: John Smith <xq.com> Date: Fri May 29 19:57:33 2021 -0700 Increase log output to 30 from 25

如果Jessica喜歡她所看到的，她可以將John的新作品合并到她當地的分支機構中：featureA

$ git checkout featureA Switched to branch 'featureA' $ git merge origin/featureA Updating 3300904..aad881d Fast forwardlib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)

最后，Jessica 可能希望對所有合并的內容進行一些小的更改，以便她可以自由地進行這些更改，將它們提交到她的本地分支，并將最終結果推送回服務器：featureA

$ git commit -am 'Add small tweak to merged content' [featureA 774b3ed] Add small tweak to merged content1 files changed, 1 insertions(+), 1 deletions(-) $ git push ... To jessica@githost:simplegit.git3300904..774b3ed featureA -> featureA

Jessica 的提交歷史記錄現在如下所示：

在某個時候，Jessica、Josie 和 John 通知集成商，服務器上的 和 分支已準備好集成到主線中。在集成商將這些分支合并到主線之后，獲取將關閉新的合并提交，使歷史記錄如下所示：featureAfeatureBee

許多組切換到 Git 是因為這種能力讓多個團隊并行工作，在流程后期合并不同的工作線。團隊中較小的子組能夠通過遠程分支進行協作，而不必涉及或阻礙整個團隊，這是Git的一個巨大優勢。您在此處看到的工作流的順序如下所示：

分叉公共項目

為公共項目做出貢獻有點不同。因為你沒有權限直接更新項目的分支，所以你必須以其他方式將工作交給維護者。第一個示例描述了在支持輕松分叉的 Git 主機上通過分叉來貢獻。許多托管網站都支持這一點（包括GitHub，BitBucket，repo.or.cz 等），許多項目維護者都希望這種貢獻。下一節將介紹那些喜歡通過電子郵件接受貢獻補丁的項目。

首先，您可能希望克隆主存儲庫，為您計劃貢獻的補丁或補丁系列創建主題分支，并在那里完成工作。序列基本上看起來像這樣：

$ git clone <url> $ cd project $ git checkout -b featureA... work ... $ git commit... work ... $ git commit

當你的分支工作完成，你準備把它貢獻給維護者時，轉到原始項目頁面，點擊“Fork”按鈕，創建你自己的項目可寫分支。然后，您需要將此存儲庫 URL 添加為本地存儲庫的新遠程站點;在這個例子中，我們稱之為：myfork

$ git remote add myfork <url>

然后，您需要將新工作推送到此存儲庫。最簡單的方法是將您正在處理的主題分支推送到分叉存儲庫，而不是將該工作合并到您的分支中并推送它。原因是，如果您的工作未被接受或被精心挑選，則不必倒帶您的分支（Git操作在重新定基和挑選工作流中有更詳細的介紹）。如果維護者，或者你的工作，你最終會通過從他們的存儲庫中提取它來找回它。mastermastercherry-pickmergerebasecherry-pick

無論如何，您都可以通過以下方式推送您的工作：

$ git push -u myfork featureA

一旦你的工作被推送到你的倉庫，你需要通知原始項目的維護者，你有希望他們合并的工作。這通常被稱為拉取請求，您通常通過網站生成此類請求 - GitHub有自己的“拉取請求”機制，我們將在GitHub中介紹 - 或者您可以運行命令并手動將后續輸出通過電子郵件發送給項目維護者。git request-pull

該命令獲取要將主題分支拉入的基本分支以及希望它們從中拉取的 Git 存儲庫 URL，并生成您要求提取的所有更改的摘要。例如，如果 Jessica 想要向 John 發送拉取請求，并且她已在剛剛推送的主題分支上完成了兩次提交，則可以運行以下命令：git request-pull

$ git request-pull origin/master myfork The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40: Jessica Smith (1):Create new functionare available in the git repository at:git://githost/simplegit.git featureAJessica Smith (2):Add limit to log functionIncrease log output to 30 from 25lib/simplegit.rb | 10 +++++++++-1 files changed, 9 insertions(+), 1 deletions(-)

這個輸出可以發送給維護者——它告訴他們工作是從哪里分支過來的，總結了提交，并確定了新工作要從哪里拉出來。

在你不是維護者的項目中，通常更容易讓一個分支像總是跟蹤一樣，并在主題分支中完成你的工作，如果它們被拒絕，你可以很容易地丟棄它們。將工作主題隔離到主題分支中，如果主存儲庫的提示在此期間移動并且您的提交不再干凈地應用，也可以使您更輕松地重新確定工作的基礎。例如，如果您想向項目提交第二個工作主題，請不要繼續處理您剛剛推送的主題分支 - 從主存儲庫的分支重新開始：masterorigin/mastermaster

$ git checkout -b featureB origin/master... work ... $ git commit $ git push myfork featureB $ git request-pull origin/master myfork... email generated request pull to maintainer ... $ git fetch origin

現在，您的每個主題都包含在一個孤島中 - 類似于補丁隊列 - 您可以重寫，變基和修改，而不會相互干擾或相互依賴主題，如下所示：

假設項目維護者已經拉入了一堆其他補丁并嘗試了你的第一個分支，但它不再干凈地合并。在這種情況下，您可以嘗試在 之上重定該分支的基態，為維護者解決沖突，然后重新提交更改：origin/master

$ git checkout featureA $ git rebase origin/master $ git push -f myfork featureA

這會將您的歷史記錄重寫為現在看起來像在 featureA 工作之后提交歷史記錄。

由于您重新設置了分支的基數，因此必須指定 to push 命令，以便能夠將服務器上的分支替換為不是其后代的提交。另一種方法是將此新工作推送到服務器上的其他分支（可能稱為 ）。-ffeatureAfeatureAv2

讓我們再看一個可能的場景：維護者已經看過你第二個分支中的工作，并且喜歡這個概念，但希望你改變一個實現細節。您還將借此機會將工作移動到基于工程的當前分支。您基于當前分支啟動一個新分支，壓縮那里的更改，解決任何沖突，進行更改，然后將其作為新分支推送：masterorigin/masterfeatureB

$ git checkout -b featureBv2 origin/master $ git merge --squash featureB... change implementation ... $ git commit $ git push myfork featureBv2

該選項將合并分支上的所有工作并將它們壓縮到一個變更集中，生成存儲庫狀態，就好像發生了真正的合并一樣，而無需實際進行合并提交。這意味著您未來的提交將只有一個父級，并允許您從另一個分支引入所有更改，然后在記錄新提交之前進行更多更改。此外，該選項對于在默認合并過程中延遲合并提交也很有用。–squash–no-commit

此時，您可以通知維護者您已經進行了請求的更改，并且他們可以在您的分支中找到這些更改。featureBv2

通過電子郵件公開項目

許多項目已經建立了接受補丁的程序 - 您需要檢查每個項目的特定規則，因為它們會有所不同。由于有幾個較舊的，較大的項目通過開發人員郵件列表接受補丁，因此我們現在將介紹一個示例。

該工作流程與前面的用例類似 — 您可以為處理的每個補丁系列創建主題分支。不同之處在于您如何將它們提交到項目中。您不必分叉項目并推送到您自己的可寫版本，而是生成每個提交系列的電子郵件版本，并通過電子郵件將它們發送到開發人員郵件列表：

$ git checkout -b topicA... work ... $ git commit... work ... $ git commit

現在，您有兩個要發送到郵件列表的提交。您用于生成可以通過電子郵件發送到列表的 mbox 格式的文件 — 它將每個提交轉換為一封電子郵件，其中提交消息的第一行作為主題，消息的其余部分加上提交引入的修補程序作為正文。這樣做的好處是，從生成的電子郵件中應用補丁可以正確保存所有提交信息。git format-patchformat-patch

$ git format-patch -M origin/master 0001-add-limit-to-log-function.patch 0002-increase-log-output-to-30-from-25.patch

該命令將打印出它創建的修補程序文件的名稱。開關告訴 Git 查找重命名。文件最終如下所示：format-patch-M

$ cat 0001-add-limit-to-log-function.patch From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 From: Jessica Smith <xq.com> Date: Sun, 6 Apr 2021 10:17:23 -0700 Subject: [PATCH 1/2] Add limit to log functionLimit log functionality to the first 20---lib/simplegit.rb | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)diff --git a/lib/simplegit.rb b/lib/simplegit.rb index 76f47bc..f9815f1 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -14,7 +14,7 @@ class SimpleGitenddef log(treeish = 'master') - command("git log #{treeish}") + command("git log -n 20 #{treeish}")enddef ls_tree(treeish = 'master') --

2.1.0
您還可以編輯這些修補程序文件，以添加您不希望在提交消息中顯示的電子郵件列表的詳細信息。如果在修補程序的行和開頭（行）之間添加文本，開發人員可以讀取它，但修補過程會忽略該內容。—diff --git

要通過電子郵件將其發送到郵件列表，您可以將文件粘貼到電子郵件程序中，也可以通過命令行程序發送。粘貼文本通常會導致格式問題，特別是對于不能適當保留換行符和其他空格的“更智能”客戶端。幸運的是，Git 提供了一個工具來幫助你通過 IMAP 發送格式正確的補丁，這可能對你來說更容易。我們將演示如何通過Gmail發送補丁，Gmail恰好是我們最熟悉的電子郵件代理;您可以在 Git 源代碼中閱讀上述文件末尾的許多郵件程序的詳細說明。Documentation/SubmittingPatches

首先，您需要在文件中設置 imap 部分。您可以使用一系列命令單獨設置每個值，也可以手動添加它們，但最終您的配置文件應如下所示：~/.gitconfiggit config

[imap]folder = "[Gmail]/Drafts"host = imaps://imap.gmail.comuser = xq.compass = YX]8g76G_2^sFbdport = 993sslverify = false

如果 IMAP 服務器不使用 SSL，則最后兩行可能不是必需的，并且主機值將代替 。設置完成后，您可以使用 將修補程序系列放在指定 IMAP 服務器的“草稿”文件夾中：imap://imaps://git imap-send

$ cat *.patch |git imap-send Resolving imap.gmail.com... ok Connecting to [74.125.142.109]:993... ok Logging in... sending 2 messages 100% (2/2) done

此時，您應該能夠轉到“草稿”文件夾，將“收件人”字段更改為您要向其發送補丁的郵件列表，可能抄送維護者或負責該部分的人員，然后將其發送出去。

您還可以通過 SMTP 服務器發送修補程序。與以前一樣，您可以使用一系列命令單獨設置每個值，也可以在文件的 sendemail 部分中手動添加它們：git config~/.gitconfig

[sendemail]smtpencryption = tlssmtpserver = smtp.gmail.comsmtpuser = xq.comsmtpserverport = 587

完成此操作后，您可以使用 來發送補丁：git send-email

$ git send-email *.patch 0001-add-limit-to-log-function.patch 0002-increase-log-output-to-30-from-25.patch Who should the emails appear to be from? [Jessica Smith <xq.com>] Emails will be sent from: Jessica Smith <xq.com> Who should the emails be sent to? xq.com Message-ID to be used as In-Reply-To for the first email? y

然后，Git 會為您發送的每個補丁吐出一堆日志信息，如下所示：

(mbox) Adding cc: Jessica Smith <xq.com> from\line 'From: Jessica Smith <xq.com>' OK. Log says: Sendmail: /usr/sbin/sendmail -i xq.com From: Jessica Smith <xq.com> To: xq.com Subject: [PATCH 1/2] Add limit to log function Date: Sat, 30 May 2009 13:29:15 -0700 Message-Id: xq.com> X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty In-Reply-To: <y> References: <y>Result: OK

總結

在本節中，我們介紹了多個工作流，并討論了作為封閉源代碼項目小團隊的一部分與為大型公共項目做出貢獻之間的差異。您知道在提交之前檢查空格錯誤，并且可以編寫出色的提交消息。您學習了如何格式化補丁，以及如何通過電子郵件將其發送到開發人員郵件列表。在不同工作流的上下文中也介紹了合并的處理。您現在已經做好了在任何項目上進行協作的準備。

接下來，您將看到如何解決硬幣的另一面：維護Git項目。您將學習如何成為一個仁慈的獨裁者或整合經理。

總結

以上是生活随笔為你收集整理的分布式 Git - 为项目做贡献的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。