当前位置：首页 > news >正文

Git：多人协作

news 2025/2/28 11:50:52

多人协作一

准备工作

开发者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 时，就不会显示远程已经删除的分支了