Git：多人協作

多人協作一

準備工作

開發者1準備工作

開發者2準備工作

協作開發

將內容合并進master

多人協作二

開發者1進行工作

開發者2進行工作

特殊場景

將內容合并進master

之前所學習的Git操作，是為了多人協作開發做鋪墊的，因為在公司中，一個項目肯定是很多開發人員一起開發的，下面就詳細講述多人協作開發相關知識

多人協作一

首先我們制定一個多人協作的工作目標：遠程master分支下file.txt文件新增代碼"aaa"、"bbb"

目前遠程master分支下的 file.txt 文件的代碼只有兩行：

實現要求：由開發者1新增"aaa"，由開發者2新增"bbb"

條件：兩個開發者在一個分支(自己創建的分支)下協作完成

我們模擬兩個開發者時：
在我們自己的云服務器上開發，當做是第一個開發者
另一名開發者我們可以在Windows系統下，把倉庫克隆下來，當做第二個開發者

準備工作

因為是需要兩個開發者在同一個分支下協作完成，所以首先需要自己創建一個分支，我們既可以在本地創建也可以在遠程倉庫gitee上創建，下面首先演示在gitee上創建：

點擊分支：

點擊新建分支：

命名為dev：

此時就會顯示創建出的dev分支：

開發者1準備工作

首先在云服務器上進行開發者1的準備工作：

此時遠程倉庫的分支如下：

本地有一個本地master分支，還有一個遠程的master分支：

因為在遠程創建了dev分支后，本地看不到這個dev分支，所以需要 pull 拉取操作：
master和master分支會自動建立連接，所以直接直接 git pull 即可

此時本地的分支狀態如下所示：

開發者2準備工作

再在Windows系統下進行開發者2的準備工作：

創建一個文件夾，將這個 remote-gitcode 倉庫克隆到本地：

此時開發者2的分支狀態就是：

整體的狀態如下：

此時開發1和開發者2的準備工作就完成了

協作開發

下面的任務就是讓開發者1在dev分支下新增 aaa 代碼，開發者2也在dev分支下新增 bbb 代碼

首先在云服務上，查看分支的情況：

對于本地來說只有一個 master 主分支
對于遠程來說，有 master 和 dev 兩個分支

我們之前跟大家交代過了，對于所有本地的修改，必須在本地分支上進行操作，再通過 git push 的操作，將本地的提交推送至遠程的某一個分支下

我們不能直接切到遠程的某一個分支下進行修改，因為如果直接這樣修改，遠程倉庫的代碼直接被改變，那么 push、pull 操作還有什么意義呢，所以 git 是不支持去切換到遠程的某一個分支下進行開發的

而此時我們本地是沒有 dev 分支的，所以我們可以創建一個本地分支出來，下面執行：
git checkout -b dev origin/dev

上述命令的意義是：

在本地創建一個 dev 分支，并切換到本地的 dev 分支上
將本地的 dev 分支和遠程的 dev 鏈接起來

我們想要查看建立的連接，可以執行 git branch -vv：

之所以要這樣建立連接，意義就是：
在我們后徐操作中，想要執行 git push / git pull 這些命令時，就可以直接執行?git push / git pull，不需要在后面跟上非常長的后綴來建立連接了

下面就可以在本地的 dev 分支上對 file.txt 文件進行修改了，添加上 aaa：

修改完成后，執行 add、commit 命令，再調用 git status 查看狀態，提示我們接下來需要執行 git push 操作推送到遠程倉庫中去：

由于上面已經將本地的 dev 分支和遠程的 dev 分支建立好連接了，所以直接執行 git push 即可：

此時就推送到遠程了，接下來觀察遠程倉庫的 dev分支下的 file.txt 文件是否發生了改變：

開發者1的工作就完成一大半了，此時遠程倉庫的 dev 分支的 file.txt 文件中也有了 aaa 內容

下面是開發者2進行操作，在剛剛克隆倉庫的位置，打開 git bash here，進行命令行式的操作，查看當前的分支：

下面在 Windows 系統下也創建一個 dev 分支，一般建議與遠程倉庫的 dev 分支進行連接，但是上面已經演示了連接的情況，所以在開發者2這里就演示不連接的情況
直接執行 git checkout -b dev：

此時查看連接情況，發現確實本地的 dev 分支并沒有與遠程倉庫的 dev 分支建立連接：

此時因為我們沒有連接，如果直接執行 git pull 命令的話，就會報錯，并提示我們需要執行下面框出來的操作才能正確的 pull：

所以我們就將這個復制下來，將 <branch> 修改為 dev 即可：

此時再執行 git branch -vv 查看連接情況，就可以發現本地的 dev 分支與遠程的 dev 分支建立了連接：

由于開發者2在克隆的時候，遠程倉庫的 file.txt 文件中只有前兩行代碼，還沒有開發者1新增的 aaa 內容，這是正常的，開發者2的工作內容就是新增自己的 bbb 即可，所以直接打開 file.txt，新增 bbb：

保存退出后，執行 add、commit、push 操作，但是卻有下面的報錯：

報錯信息告訴我們：遠程拒絕了我們的推送操作，是當前的分支和遠程的分支是有一定差異的，差異的原因是遠程倉庫的 dev 分支是有 aaa 的，而本地倉庫的 dev 分支下是有 bbb 內容的，都是在 file.txt 文件中存在的，此時它們是有一個沖突的

如果git允許推送，那么 aaa 和 bbb 都是在 file.txt 的第三行的內容，git并不清楚我們是需要 aaa 還是需要 bbb，所以git就直接拒絕推送請求，我們需要人工手動的解決這個沖突

上面的黃色字體也告訴我們解決方法就是：先執行 git pull 將遠程倉庫的 dev 分支的內容拉取到本地來，我們進行完沖突解決后，再推送至遠程即可：

此時 file.txt 文件如下：

我們手動將內容改為我們想要的即可：

修改完后，再執行 add、commit、push 三板斧，就能夠推送成功了：

下面打開遠程倉庫 dev 分支下的的 file.txt 文件，就有了 aaa 和 bbb 的代碼：

此時就做到了開發者1和開發者2在遠程的 dev 分支上做到了新增的代碼，下面完成最后一步，在 master 分支上也新增這兩行代碼，也就是將 dev 合并到 master 分支上

將內容合并進master

遠程倉庫的 dev 分支上多了 aaa 和 bbb，但是 master 分支上并沒有多這兩行代碼

原因就是 master 分支沒有進行 merge 操作，沒有將 dev 分支的內容 merge 進 master 分支下

接下來有兩種方式可以合并：

提出一個 pull request 合并申請單，管理員同意后，就可以進行 merge 操作了(這里的 pull request 在前面有提到過)
讓本地的 master 分支 merge dev 分支，再將本地的 master 分支 push 推送到遠程倉庫中

方式一：PR申請單

?pull request 操作如下，點擊新建：

源分支選擇 dev 分支，目標分支選擇 master 分支，再添加相關的信息，點擊創建就可以完成：

這種方式中的審查員，實際上在公司中對應的是老板或項目經理，是為程序員縮寫的代碼提供保障性的

方式二：本地合并再推送

我們上面的開發者1和開發者2都完成了自己的任務，以開發者1為例，開發者1并沒有開發者2新增的 bbb 代碼，所以開發者1需要先 pull 遠程的 dev 分支，保證代碼的完整性

開發者1此時的 file.txt 文件內容為：

執行 git pull 操作后：

此時對于開發者1來說 dev 分支上就有了 aaa 和 bbb 了

在之前提到過，如果直接使用 master 分支合并 dev 分支，可能會發送沖突，而 master 分支是比較重要的，不應該出現這些問題

所以我們的策略就變為：使用 dev 分支去合并 master 分支，如果有沖突的話就在本地的 dev 分支下解決，不會影響 master 分支，如果沒有沖突再讓 master 分支合并 dev 分支即可

在 dev 分支合并 master 前，需要保證此時本地的 master 分支是最新的，因為遠程的 master 分支有可能會添加新的內容，所以第一步是本地的 master 分支執行 pull 操作，保證本地的 master 分支與遠程的 master 分支的內容是一樣

master 分支執行 pull 操作

dev merge master

此時 dev 分支合并 master 分支后并沒有沖突問題，所以就可以?master 分支上合并 dev 分支：

此時本地倉庫的 master 分支的 file.txt 文件為：

本地 master 推送到遠程倉庫的 master：

此時遠程倉庫中 master 分支下的 file.txt 文件，就有了 aaa 和 bbb 內容了：

到此為止，就完成了我們的目標，此時我們創建的 dev 分支就沒有任何用處了，就可以進行刪除操作了

點擊管理：

點擊右邊的刪除圖標：

此時就只剩下 master 分支了：

總結一下，在同一分支下進行多人協作的工作模式通常是這樣:

首先，可以試圖用 git push origin branch-name 推送自己的修改
如果推送失敗，則因為遠程分支比你的本地更新，需要先用 git pull 試圖合并
如果合并有沖突，則解決沖突，并在本地提交
沒有沖突或者解決掉沖突后，再用 git push origin branch-name推送就能成功
功能開發完畢，將分支 merge 進 master，最后刪除分支

因為上述的第三點，合并有沖突需要解決沖突，而解決沖突是較為麻煩的，所以在同一分支下多人協作是不常見的，所以接下來所講的多人協作二，是在不同分支下的多人協作的場景

多人協作二

首先我們制定一個多人協作的工作目標：遠程 master 分支下新增 function1 和 function2 文件

實現要求：由開發者1新增 unction1 ，由開發者2新增 function2

條件：兩個開發者在不同分支下協作完成(各自讓某一個功能私有某一個分支)

我們目前關注的倉庫如下：

下面就需要創建分支完成任務了，有兩種方式：

遠程創建分支
本地創建分支，先 pull，再?push 到遠程

推薦第一種，因為遠程創建分支是直接基于遠程的 master 分支進行創建，可以保證是最新的代碼，而本地創建分支并不能保證是最新的代碼

開發者1進行工作

首先在開發者1這里，創建一個 feature-1 分支，并切換到 feature-1 分支：

在這個分支中創建 function1 文件：

接著執行 add、commit 操作：

由于本地和遠程沒有建立鏈接，所以還不能進行 push 操作，但是我們可以直接將 feature-1 分支直接推送到遠端：

git push origin feature-1

此時觀察分支情況，本地和遠端都有了 feature-1 分支：

在 gitee 上也能看到新增的 feature-1 分支：

feature-1 分支中的 function 文件也有了新增的代碼：

所以此時的圖示就變為了：

開發者2進行工作

查看 Windows 下開發者2的分支情況：

此時處于 dev 分支，我們切換到 master 分支上：

此時的 master 分支不是最新的，因為在上面的多人協作一中，我們已經給 file.txt 文件中新增了 aaa 和 bbb，而開發者2的 file.txt 的內容并沒有更新：

所以首先需要 pull，拉取最新的代碼：

此時就可以新建一個 feature-2 分支：

由于是在 Windows 下，所以直接右鍵創建一個 function2 文件即可：

此時與開發者1一樣，先 add、commit：

再直接將 feature-2 分支推送到遠端：?git push origin feature-2

此時 gitee 上就有三個分支了：

此時的 feature-2 分支下的 function2 文件內容也推送上來了：

我們發現不同的開發者在各自的分支中開發，最終推送到遠端，是沒有沖突的，直到最后合并時才可能會有沖突

相比于多人在同一分支開發來說，多人在不同分支下開發是非常方便的?

此時的圖示變為：

特殊場景

正常情況下，兩個開發者就可以在自己的分支上進行專業的開發了

但是天有不測風云，你的小伙伴突然生病了，但需求還沒開發完，需要你幫他繼續開發，于是他便把 feature-2 分支名告訴你了，這時你就需要在自己的機器上切換到 feature-2 分支幫忙繼續開發，所以下面需要開發者1幫助開發者2完成

也就是開發者1需要切換到 feature-2 分支下進行開發

開發者1的分支情況如下，看不到遠程的 feature-2 分支：

所以第一步是使用 pull 拉取遠程的 feature-2 分支：

git pull 的兩種場景：

拉取分支內的內容 (需要關聯遠程倉庫的分支)
拉取倉庫的內容

拉取到遠程的 feature-2 分支后，我們在本地也創建 feature-2 分支，并關聯到遠程的 feature-2 分支：git checkout -b feature-2 origin/feature-2

下面就 vim 打開 function2 文件，繼續開發：

此時就可以進行 add、commit、push 三板斧了，因為剛剛建立好鏈接了，所以可以直接 push：

此時遠程倉庫 gitee 上，feature-2 分支上的 function2 文件內容也更新了：

到這時，開發者2的病好了，開發者2就繼續在 Windows 下開發，此時開發者2并看不到開發者1幫忙寫的代碼：

所以此時開發者2就需要進行 pull 拉取操作，將遠程倉庫的 feature-2 分支的內容同步到本地分支上，但是此時直接 pull 是會失敗的，因為開發者2 并沒有與遠程倉庫的 feature-2 分支建立連接

所以下面先建立連接，再 pull：

查看 function2 文件，拉取成功：

開發者2 再加上最后一行內容：

繼續執行 add、commit、push：

遠程倉庫 gitee 也同步了更新的代碼：

將內容合并進master

開發者1和開發者2的工作已經完成了，最后一件事就是將 feature-1 分支和 feature-2 分支合并進 master 主分支中

這次的合并，我們可以選擇發起 pull request 申請單的方式合并，并點擊創建 pull request：

假設作為審查人員的我們，打開 pull request，往下翻，點開文件，就能看到源分支和目標分支的差異：

如果代碼沒有問題，我們就點擊已閱，通過，點擊提交：

接著點擊合并分支：

點擊接收 pull request：

此時 pull request 上方，就會顯示已合并：

此時 master 分支就有了 function2.txt?文件了：

也就是下面的流程：

feature-2 分支已經合并完成了，現在還剩下 feature-1 分支，有一些細節需要注意，下面詳細說明

目前的合并流程為：

期望的操作是：

但是在 feature-1 合并進 master 主分支時，可能是有沖突的，所以如果有沖突的話是需要解決沖突的，這里就又回到了我們之前說到的解決沖突的方法

我們不能直接用 master 分支合并 feature-1 分支，這里有可能將 master 分支在解決沖突的過程中解決壞了，所以方法就是：先讓 feature-1 分支去合并 master 分支，合并完沖突后，再讓 master 分支合并 feature-1 分支，此時就不會有什么問題了

所以圖示為：

下面實操一下上述的兩步

feature-1 分支 merge master 分支

首先切到本地的 master 分支，pull 一下代碼，不論本地當前是不是最新的代碼，這都是一個好習慣：

再切換到 feature-1 分支上，讓 feature-1 分支 merge master 分支：git merge master
此時出現下面的頁面，表示 merge 的時候沒有出現任何沖突，按下 Ctrl + x 退出即可：

此時本地合并完后，執行 push 推送到遠程倉庫：

下面 feature-1 分支合并完 master 分支后，沒有任何沖突，此時就可以按照前面 master 分支合并 feature-2 分支的方式合并

也就是提交 pull request，審核人員審核通過即可：

接著已閱、通過、提交：

?再點擊接受 pull request

此時 master 分支上，關于開發者1和開發者2的代碼就全部合并上了：

最后再刪除 feature-1 分支和 feature-2 分支即可

git branch -a 打印已被刪除的遠程分支

我們在遠程倉庫中已經刪除了 feature-1 和 feature-2 分支了，遠程倉庫只剩 master 分支了：

但是 git branch -a 仍然會打印已被刪除的遠程分支

我們可以執行：git remote show origin，用于展示遠程分支的情況：

在我們已經刪除的 dev、feature-1、feature-2 分支后顯示是 stale 狀態，也就是陳舊的狀態，推薦我們執行 git remote prune origin，即可移除執行 git branch -a 時已經在遠程刪除的這幾個分支
此時再次執行?git branch -a 時，就不會顯示遠程已經刪除的分支了