在版本控制術語中，如果你 “fork” 一個倉庫，則是指複製它。特別是當你 fork 屬於別人的倉庫時，你將製作他們倉庫的完全一樣的副本，之後這個副本便變成你的。

“fork” 的概念也不同於”克隆”。在克隆倉庫時，你也會獲得完全一樣的倉庫副本，但克隆發生在本地計算機上，並且克隆的是遠端倉庫。當你 fork 倉庫時，會建立遠端倉庫的一份新副本。新副本也是一個遠端倉庫，但它現在屬於你。

fork 不在命令列上執行；也不存在 git fork 命令。

修改克隆的倉庫

當我們嘗試通過 git clone 克隆別人的倉庫到本地後，修改其中的檔案並提交，然後將本地倉庫再推送到遠端倉庫時，會出現類似如下內容：

由於我不是倉庫所有者，所以我沒有許可權自動向遠端倉庫新增我的更改。也就是說，如果一個倉庫不屬於你的帳戶，那麼你便不具有修改它的許可權。

這裡 fork 就要派上用場了！你不能直接修改原倉庫，但如果你將倉庫 fork 到自己的帳戶中，便擁有完全控制權了。

如上圖所示，fork 專案後你的 GitHub 配置檔名稱旁邊會顯示新的專案名稱。此外名稱下面還會說明原始專案所在的位置。現在你可以 fork GitHub 上的任何公共倉庫 - 即你可以將倉庫複製到自己的帳戶中，並對獲得的副本擁有完全控制權。

fork 推送/拉取

fork 是一種在託管服務上完成的操作，如 GitHub。fork 倉庫會建立與原始倉庫完全相同的副本，並將該副本移動到你的帳戶。你對 fork 的倉庫擁有完全控制權。修改 fork 的倉庫不會更改原始倉庫。

檢視現有工作

我們可以使用非常強大的 git log 命令，查明其他開發者所做工作的詳細資訊。

使用 git shortlog 按作者對 commit 分組

它顯示了按作者字母順序排序的人名所有 commit。在上面的截圖中，我們可以看到：

• Abby Armada 在倉庫中新增了一個 commit
• Addy Osmani 新增了八個 commit
• Adriano Caheté 新增了一個 commit
• Akshay Iyer 新增了一個 commit

如果我們只想看到每個開發者的 commit 數量，我們可以新增幾個選項：用 -s 僅顯示 commit 的數量（而不是每個 commit 的訊息），以及用 -n 來按數量排序（而不是按作者姓名的字母順序）。

$ git shortlog -s -n

如果我們只想看到 Addy Osmani 的這八個 commit 呢？

使用 --author 選項篩選 commit

另一種顯示某個作者所有 commit 的方法是使用常規的 git log 命令，但包含 --author 選項來篩選所述作者的 commit 。

$ git log --author="Addy Osmani"

注意，在上面開發者姓名列表中，我們看到了 “Paul Irish” 和 “Paul Lewis”，如果我們執行下面的命令：

$ git log --author=Paul

這將顯示所有姓名以 "Paul" 開頭的作者的 commit。所以它將顯示 Paul Irish 和 Paul Lewis 的 commit 。

注意上一個命令中使用的引號。如果它不加引號，像 git log --author=Paul Lewis，就無法正常執行。如果不加引號，Git 會認為 Lewis 不是 "author" 選項的一部分，從而導致錯誤。

使用 --grep 選項篩選 commit

在講解“按搜尋內容篩選 commit”這部分之前，我認為我需要強調一下編寫好的描述性提交說明的重要性。編寫描述性提交說明，會使你之後能很輕鬆地搜尋提交說明，找到你想要的東西。

那麼這些詳細資訊為何重要呢？一方面，你將能更容易地回頭檢視對倉庫所做的更改，其他人也更容易檢視更改。另一方面是你將能根據當前說明或描述區域中的資訊篩選 commit 。

另外記住，如果提交說明不足以解釋 commit 的內容，則你可以在描述區域中提供關於該 commit 用途的詳細說明。

我們可以使用 --grep 選項篩選 commit 。以篩選提到 “bug” 一詞的 commit ：

$ git log --grep=bug
$ git log --grep bug

注意，空格在這裡也是一個問題。如果你嘗試搜尋包含多個詞且單詞之間有空格的內容，則需要將空格也包含在引號內。例如，要搜尋 unit tests，你需要使用以下命令 git log --grep="unit tests"。

Grep 是一個模式匹配工具，如果你執行 git log --grep "fort"，那麼 Git 將顯示順序包含字元 f、o、r、t 的 commit 。

有關 Grep 的更多資訊

確定任務

假設你正在使用某個第三方庫構建一個專案。如果在使用此第三方庫時遇到 bug 或拼寫錯誤，該怎麼辦？

通過向原專案的維護者傳送一個請求，將你的程式碼更改包含在其中，請求維護者將這些更改拉取到原專案中。這種請求稱為“拉取請求”（Pull Request）。

但是，你如何以原專案維護者能接受的方式實際對專案做出貢獻，並使他最終合併你的更改？記住，你要做的第一件事，是在專案中尋找一個名為 CONTRIBUTING.md 的檔案。

CONTRIBUTING.md 檔案

CONTRIBUTING.md 檔案的名稱特別採用全大寫，以方便查詢。此檔案列出了你要為專案做出貢獻時所應遵循的資訊。在開始任何開發工作之前，應先找到此檔案。

GitHub Issues

注意，這裡說的”Issues（問題）”並不代表實際存在錯誤，它可以是需要對專案進行的任何改變。GitHub 的問題跟蹤器相當高階。每個問題都可以：

• 應用一個或多個標籤
• 被分配給個人
• 確定一個里程碑（例如問題將由下一個主要版本解決）

但問題跟蹤器最重要的一個方面在於，每個問題都可以有自己的評論區，使開發者圍繞這個問題展開對話。

Issue 的另一個很棒的功能在於：

• 你可以訂閱（Subscribe）某個 Issue ，這樣你便會獲得新評論和程式碼更改的通知
• 你可以就具體變更與專案維護者持續交流

在向某個檔案貢獻任何內容之前，請檢視 CONTRIBUTING.md 中的說明。然後檢視專案的 Issue，看是否有哪些與你要貢獻的內容類似。如果有，則訂閱該 Issue 並閱讀現有的對話，看你是否可以提供幫助。如果你檢視了 Issues 列表，沒有看到與你要做的事情類似的內容，那麼你可以建立自己的新 Issue（New issue）。

New Issue 頁

新建問題頁好的一點在於，如果專案有 CONTRIBUTING.md 檔案，它會在頁面頂部顯示一個提醒，要求你檢視有關如何為專案做貢獻的準則。點選”guidelines for contributing”連結，可以轉至 CONTRIBUTING.md 檔案。

與編寫描述性的提交說明一樣，你在建立問題時，要給它一個資訊豐富的標題，簡要說明你想要做的事情。然後，在評論部分，提供大量關於此更改的詳細資訊，可以是你為什麼認為此更改有必要，也可以是它如何改進專案。

特性分支

組織你想貢獻給專案的一系列 commit 或更改的最佳方法，是將它們全部放在一個特性分支上。我說的特性分支是什麼意思呢？與主分支不同，主分支是儲存整個專案的所有 commit 的預設分支，而特性分支僅儲存單個概念或單個更改區域的 commit 。

例如，如果登入某個網站的登入表單有問題，則解決此特定問題的分支名稱可以叫做：

• login
• login-bug
• signup-bug
• login-form-bug
• 等等。

要記住的一點是，有時專案會對特性分支的命名有特定要求。例如，如果一個分支將要解決錯誤修復，那麼許多專案會要求新增一個 bugfix- 字首。回到我們處理登入表單錯誤的分支，它得被命名為 bugfix-login-form。所以一定要閱讀 CONTRIBUTING.md 檔案，確定專案是否對特性分支的命名提供了特別說明。

一般實踐

編寫清晰、描述性的提交說明。你的分支名稱和提交說明描述得越清楚，專案維護者用於詢問你的程式碼的用途，或者自己去深入瞭解程式碼的時間就越少。專案維護者需要做的工作越少，將你的更改納入專案的速度就越快。

使用短小而明確的 commit。不要進行大量 commit，記錄 10 多個檔案和數百行程式碼的更改。最好頻繁多次地進行小的 commit，只記錄很少數量的檔案和程式碼更改。

更新 README，如果你新增的任何程式碼更改會使專案發生極大的變化，則應更新 README 檔案以向其他人說明此更改。