## 一、克隆倉庫到本地 打開實驗環境，以組員的身份克隆自己的 work 倉庫到實驗環境，由于之前已經設置了實驗環境的 SSH 公鑰到 GitHub，所以我們使用 git 開頭的地址來克隆：  鏈接的結尾 .git 是不需要的：  ## 二、完成任務并推送到自己的倉庫 現在我們要完成組長倉庫的一個 issue，注意每個 issue 在創建后都會生成一個編號，我們首先完成 1 號 issue：  創建文件，添加到暫存區，提交，查看本地倉庫分支狀態：   注意在執行 commit 命令時，備注信息里有個 “fix #1”，這是必要的，當備注信息中含有此字樣的 commit 出現在組長倉庫，倉庫中編號為 #1 的 issue 就會自動關閉。類似的字樣還有 “fixes #xxx、fixed #xxx、closes #xxx、close #xxx、closed #xxx”，這些并不重要，選擇字母最少的 fix 就可以了。當然偶爾忘記寫這個字樣也不要緊的，issue 可以手動關閉，甚至關掉的 issue 還能再開。 完成以上操作，組員的 GitHub 倉庫會發生變化，新增一個版本號為 b374 的提交：  ## 三、提 PR & 檢查合并 PR 接下來，怎么把修改從組員的倉庫添加到組長的倉庫呢？這就用到了 pull request 方法，簡稱 PR。這個詞組比較費解，兩個詞都有動詞屬性，字面意思是 “拉，請求”，可以理解為這是一個名詞性詞組，意為 “允許被拉取的請求”，創建一個 PR 就是從甲分支向乙分支提一個請求，該請求中有一個或多個提交，對方覺得可以、沒問題，就合并（merge) 這個請求，也就是把請求中所有提交的修改增加到乙分支上，整個過程簡稱 “提 PR”、“檢查合并 PR”。提 PR 既可以在倉庫內，也可以跨用戶跨倉庫。 好，現在我們從組員的 work 倉庫 master 分支給組長的 work 倉庫 master 分支提一個 PR：  如下圖所示，仔細檢查紫色框中的內容是否正確，再看綠色橢圓形框中的綠色字樣 “Able to merge.”，說明這個 PR 中的修改跟目標分支沒有沖突：  從上圖還可得知一些信息：該 PR 里有 1 個提交，1 個文件改動，1 個貢獻者。點擊上圖綠色按鈕跳轉到確認頁面，再次點擊下圖綠色按鈕即可完成本次 “提 PR” 工作：  完成后，頁面自動跳轉到組長的 work 倉庫 PR 的合并頁面：  該頁面只有參與項目協作的成員有權限進入，當前 GitHub 的登錄用戶是組員，所以可見，且對這個倉庫有完全的管理權限，除了刪除倉庫。當然了，檢查合并 PR 的權限也是有的。重要的一點：提了 PR 之后，一定要求參與項目的其他成員來檢查合并，不要自己來，盡管自己有權限。 上圖中綠色按鈕是個下拉按鈕，合并 PR 的方法有三種，分別解釋一下： Create a merge commit ：這種方式會在組長倉庫的 master 分支上生成一個新的提交，且保留 PR 中的所有提交信息。這是一種常規操作，用得最多。 Squash and merge ：壓縮合并，它會把 PR 中的全部提交壓縮成一個。此方法的優點就是讓提交列表特別整潔。一個 PR 里有很多提交，每個提交都是很細小的改動，保留這些提交沒什么意義，這種情況就使用此方法合并 PR。 Rebase and merge ：這種方法不會生成新的提交，例如 PR 中有 6 個提交，用此方法合并后，組長倉庫也會新增 6 個提交。注意，這些提交的版本號與組員的提交不同，此外完全一樣。 現在切換到另一個登錄組長賬號的瀏覽器，打開合并 PR 的頁面，用第一種方法合并：  這就是第一種方式合并的結果，生成了一個新的提交，這個提交里沒有修改。因為樣子不太美觀，這是我最不喜歡用的方式。仔細看上圖的 issue，變成了 1 個，也就是說在合并 PR 后，#1 issue 被關閉了。 以上就是一次完整的修改、提交、推送、提 PR、合并 PR 的過程。 需要注意的一點：從 A 向 B 提 PR 后，在 PR 合并或關閉前，A 上所有新增的提交都會出現在 PR 里。 ## 四、同步主倉庫 因為組長的 master 分支新增了一個空提交，所以需要讓組員的倉庫同步組長的倉庫，使它們的提交版本一致。作為組員，要時刻保持自己的 master 分支與組長的一致，以避免在下次提 PR 時出現沖突，該操作叫做 “同步主倉庫”，組長的倉庫就是主倉庫。 提 PR、合并 PR 只能在 GitHub 頁面上操作。同步主倉庫是要用 Git 操作的。現在回到實驗環境中操作。首先，使用 remote 系列命令來增加一個關聯主機，執行 git remote add [主機名] [主倉庫的地址]，注意，主倉庫的地址使用 https 開頭的：  如上圖所示，主機名是隨意定義的，只要不是 origin 就可以，因為自己的倉庫地址對應的主機名是 origin，主倉庫的主機名通常定義為 up 或 upstream，這個主機名其實就是一個變量，它的值就是倉庫地址，例如 git push origin master 完全等于 git push git@github.com:Manchangdx/work master 。 如此說來，關聯主倉庫后也沒什么變化嘛，確實如此，即使地址寫錯也不會報出來。現在可以使用前面課程介紹過的 fetch 命令來拉取主倉庫的全部分支信息到本地倉庫了，我有時使用這個命令看上一個命令是否有拼寫錯誤：   如何同步主倉庫哩？方法有二，一是執行 git pull --rebase up master ，此命令需聯網，二是執行 git rebase up/master，此命令不聯網，因為前面已經執行了 git fetch up 這個需要聯網的命令，本地已經有了最新的主倉庫 master 分支信息，所以可以這么操作。 總結一下：git pull --rebase = git fetch + git rebase。現在使用方法二來同步：   同步主倉庫已完成。現在可以繼續修改提交自己的 master 分支了。然后一并推送到自己的遠程倉庫。 以上是在自己 Fork 的倉庫里進行修改的過程。還有一種常用的方式，就是不用 Fork，直接克隆組長的倉庫到本地，然后各自創建自己的分支，在自己的分支上進行修改提交，最后從自己的分支向 master 分支提 PR。方式不同，原理一樣。 關于多人協作的 Git 操作就到這里了。