【Git】多人协作 -- 详解

一、多人协作（1）

⽬前，我们所完成的工作如下：

基本完成 Git 的所有本地库的相关操作，git 基本操作，分支理解，版本回退，冲突解决等等。
申请码云账号，将远端信息 clone 到本地，以及推送和拉取。

是时候做最重要的一件事情了，实现多人协作开发。

为了做这件事情，需要先做一些准备工作。我们之前已经将项目 clone 到了指定目录，如：

完成任务：

在 Windows 环境下，再 clone 同一个项目仓库，来模拟和我们⼀起协作开发的另一名小伙伴：

找一个新的文件夹，进入文件夹后右键：

clone 成功：

注意：这里是模拟了两个用户。但在实际开发中，每个用户都有属于自己的 gitee/github 账号，如果要多人进行协同开发，必须要将用户添加进开发者，用户才有权限进行代码提交：

邀请用户：

到此，相当于有了两个用户，分别在 Linux 和 Windows 上针对于同个项目进行协作开发，我们的准备工作到此结束。

目前，我们的仓库中只有一个 master 主分支，但在实际的项目开发中，在任何情况下其实都是不允许直接在 master 分支上修改代码的，这是为了保证主分支的稳定。所以在开发新功能时，常常会新建其他分支，供开发时进行迭代使用。那么接下来，就让我们在 gitee 上新建 dev 远程分支供我们使用：

创建成功：

创建成功的远程分支是可以通过 Git 拉取到本地来，以实现完成本地开发工作。接下来让我们和另一名开发的小伙伴都将远程仓库进行一次拉取操作。

对于我们要操作的是：

注意：之前讲的 git branch 只能查看本地分支，要查看远程分⽀需要加上 -r 选项。但前提是要 pull ⼀下拉取最新的远端仓库，才能看到最新的内容。

拉取后便可以看到远程的 dev 分支，接着切换到 dev 分支供我们进行本地开发。要说明的是，我们切换到的是本地的 dev 分支，根据示例中的操作，会将本地分支和远程分支的进行关系链接。

对于另一名小伙伴要操作的是：

现在，我们就可以和小伙伴在 dev 上完成开发。

首先，让我们在 dev 分支上进行一次开发，并 push 到远程：

来看看码云上目前仓库的状态：

至此，我们已经将代码成功推送至码云，接下来假如小伙伴要和我们协同开发，碰巧也要对 file.txt 文件做修改，并试图推送：

这时推送失败，因为小伙伴的最新提交和你推送的提交有冲突，解决办法也很简单，Git 已经给出了提示，先用 git pull 把最新的提交从 origin/dev 抓下来，然后再在本地进行合并，并解决冲突，再推送。操作如下：

解决冲突，重新推送：

此时，在远端的码云就能够看到我们的新提交了：

由此，两名开发者已经开始可以进行协同开发了，不断的 git pull/add/commit/push，遇到冲突就使用之前讲的冲突处理解决掉冲突。

对于我们来说，要想看到小伙伴的代码，只需要 pull 一下即可：

最后不要忘记，虽然我们是在分支上进行多人协作开发，但最终的目的是要将开发后的代码合并到 master 上去，让我们的项目运行最新的代码。接下来我们就需要做这件事情了：

切换至 master 分支，pull 一下，保证本地的 master 是最新内容，合并前这么做是一个好习惯。

切换至 dev 分支，合并 master 分⽀，这么做是因为如果有冲突的话，可以在 dev 分支上进行处理，而不是在 master 上解决冲突，这么做也是一个好习惯。

切换至 master 分支，合并 dev：

将 master 分支推送到远端：

此时再查看远端仓库，master 已经是最新代码了：

此时，dev 分支对于我们来说就没用了，那么 dev 分支就可以被删除掉。我们可以直接在远程仓库中将 dev 分支删除掉：

总结一下，在同一分支下进行多人协作的工作模式通常是这样：

首先，可以试图用 git push origin branch-name 推送自己的修改。
如果推送失败，是因为远程分支比我们的本地更新，需要先用 git pull 试图合并。
如果合并有冲突，就解决冲突，并在本地提交。（解决冲突是一件很麻烦的事情）
没有冲突或者解决掉冲突后，再用 git push origin branch-name 推送就能成功。
功能开发完毕，将分支 merge 进 master，最后删除分支。

二、多人协作（2）

完成任务：

一般情况下，如果有多需求需要多人同时进行开发，是不会在一个分支上进行多人开发，而是一个需求或一个功能点就要创建一个 feature 分支。现在同时有两个需求需要我们和小伙伴进行开发，那么我俩便可以各自创建一个分支来完成自己的工作。前面我们已经了解了可以从码云上直接创建远程分支，其实在本地创建的分子也可以通过推送的方式发送到远端。在这个部分我们就来用一下这种方式。

对于我而言，可以进行以下操作：

新增本地分支 feature-1 并切换

新增需求内容 —— 创建 feature1 文件

将 feature-1 分支推送到远端

对于小伙伴来说，可以进行以下操作：

创建并切换到 feature-2 分支

在分支下为需求新增 function2 文档

将 feature-2 分支推送至远端

此时在本地看不见伙伴新建的文档，他也看不见我们新建的文档，并且推送各自的分支时，并没有任何冲突，我俩不受对方的影响，用起来就很舒服。

再来看下远端码云上此时的状态：

对于我们的 feature-1 分支：

对于小伙伴的 feature-2 分支：

正常情况下，我俩就可以在自己的分支上进行专业的开发了。但万一有天小伙伴突然生病了，但需求还没开发完，需要我帮他继续开发，于是他就把 feature-2 分支名告诉我。这时我就需要在自己的机器上切换到 feature-2 分支帮忙继续开发，要做的操作如下：

必须先拉取远端仓库内容

可以看到远程已经有了 feature-2

切换到 feature-2 分支上，可以和远程的 feature-2 分支关联起来，否则将来只使用 git push 推送内容会失败

切换成功后，便可以看见 feature-2 分支中的 function2 文件了，接着就可以帮小伙伴进行开发：

继续开发

推送内容

查看远程状态，推送成功了：

这时小伙伴已经修养的差不多，可以继续进行自己的开发工作，那么他首先要获取到我们帮他开发的内容，然后接着我们的代码继续开发。或者我们已经帮他开发完了，那他也需要在自己的电脑上看看我们帮他写的代码：

可以发现代码没有 pull 下来。

Pull 无效的原因是：小伙伴没有指定本地 feature-2 分支与远程 origin/feature-2 分支的链接。

根据提示，设置 feature-2 和 origin/feature-2 的链接即可：

目前，小伙伴的本地代码和远端保持严格一直。我和小伙伴可以继续在不同的分支下进行协同开发了。

各自功能开发完毕后，我们需要将代码合并到 master 中才算真正意义上的开发完毕。

新建一个 Pull Request，让 feature-2 分支合并到 master 分支上：

让 feature-1 分支合并到 master 分支上：

切换至 master 分支，pull 一下，保证本地的 master 是最新内容，合并前这么做是⼀个好习惯

切换至 feature-1 分支，合并 master 分支。这么做是因为如果有冲突，可以在 feature-1 分支上进行处理，而不是在 master 上解决冲突，这么做也是⼀个好习惯

（1）由于 feature-1 分支已经 merge 进来了新内容，为了保证远程分支最新，所以最好 push ⼀下。
（2）要 push 的另⼀个原因是因为在实际的开发中，master 的 merge 操作一般不是由我们自己在本地进行操作，其他⼈员或某些平台 merge 时，操作的肯定是远程分支，所以就要保证远程分支的最新。
（3）如果 merge 出现冲突，不要忘记需要 commit 才可以 push。