五、多人协作 Git 部分

Git 多人协作

克隆仓库到本地

打开实验环境,以组员的身份克隆自己的 work 仓库到实验环境,由于之前已经设置了实验环境的 SSH 公钥到 GitHub,所以我们使用 git 开头的地址来克隆:

7212994-abe420c2824d43fd.png
501.png

链接的结尾 .git 是不需要的:

7212994-512690a928a58a5a.png
502.png

现在我们要完成组长仓库的一个 issue,注意每个 issue 在创建后都会生成一个编号,我们首先完成 1 号 issue:

7212994-58aa20d4c65f9479.png
503.png

创建文件,添加到暂存区,提交,查看本地仓库分支状态:

7212994-a296b623d0c15233.png
504.png
7212994-bf47806a8e99fd39.png
505.png

注意在执行 commit 命令时,备注信息里有个 “fix #1”,这是必要的,当含备注信息中含有此字样的 commit 出现在组长仓库,仓库中编号为 #1 的 issue 就会自动关闭。类似的字样还有 “fixes #xxx、fixed #xxx、closes #xxx、close #xxx、closed #xxx”,这些并不重要,选择字母最少的 fix 就可以了。当然偶尔忘记写这个字样也不要紧的,issue 可以手动关闭,甚至关掉的 issue 还能再开。

完成以上操作,组员的 GitHub 仓库会发生变化,新增一个版本号为 b374 的提交:

7212994-5441471b5903dcf3.png
506.png

接下来,怎么把修改从组员的仓库添加到组长的仓库呢?这就用到了 pull request 方法,简称 PR。这个词组比较费解,两个词都有动词属性,字面意思是 “拉,请求”,可以理解为这是一个名词性词组,意为 “允许被拉取的请求”,创建一个 PR 就是从甲分支向乙分支提一个请求,该请求中有一个或多个提交,对方觉得可以,没问题,就合并(merge) 这个请求,也就是把请求中所有提交的修改增加到乙分支上,整个过程简称 “提 PR”、“检查合并 PR”。提 PR 既可以在仓库内,也可以跨用户跨仓库。

好,现在我们从组员的 work 仓库 master 分支给组长的 word 仓库 master 分支提一个 PR:

7212994-7b7af2a54e9854cf.png
507.png

如下图所示,仔细检查紫色框中的内容是否正确,再看绿色椭圆形框中的绿色字样 “Able to merge.”,说明这个 PR 中的修改跟目标分支没有冲突:

7212994-24a46700f61ec4ba.png
508.png

从上图还可得知一些信息:该 PR 里有 1 个提交,1 个文件改动,1 个贡献者。点击上图绿色按钮跳转到确认页面,再次点击下图绿色按钮即可完成本次 “提 PR” 工作:

7212994-3d0a948371f86b36.png
509.png

完成后,页面自动跳转到组长的 work 仓库 PR 的合并页面:

7212994-c2c3b1c91b368acc.png
511.png

该页面只有参与项目协作的成员有权限进入,当前 GitHub 的登录用户是组员,所以可见,且对这个仓库有完全的管理权限,除了删除仓库。当然了,检查合并 PR 的权限也是有的。重要的一点:提了 PR 之后,一定要求参与项目的其他成员来检查合并,不要自己来,尽管自己有权限。

上图中绿色按钮是个下拉按钮,合并 PR 的方法有三种,分别解释一下:

Create a merge commit:这种方式会在组长仓库的 master 分支上生成一个新的提交,且保留 PR 中的所有提交信息。这是一种常规操作,用得最多。

Squash and merge:压缩合并,它会把 PR 中的全部提交压缩成一个。此方法的优点就是让提交列表特别整洁。一个 PR 里有很多提交,每个提交都是很细小的改动,保留这些提交没什么意义,这种情况就使用此方法合并 PR。

Rebase and merge:这种方法不会生成新的提交,例如 PR 中有 6 个提交,用此方法合并后,组长仓库也会新增 6 个提交。注意,这些提交的版本号与组员的提交不同,此外完全一样。

现在切换到另一个登录组长账号的浏览器,打开合并 PR 的页面,用第一种方法合并:

7212994-feeeebb8cead89f2.png
512.png

这就是第一种方式合并的结果,生成了一个新的提交,这个提交里没有修改。因为样子不太美观,这是我最不喜欢用的方式。仔细看上图的 issue,变成了 1 个,也就是说在合并 PR 后,#1 issue 被关闭了。

以上就是一次完整的修改、提交、推送、提 PR、合并 PR 的过程。

因为组长的 master 分支新增了一个空提交,所以需要让组员的仓库同步组长的仓库,使它们的提交版本一致。作为组员,要时刻保持自己的 master 分支与组长的一致,以避免在下次提 PR 时出现冲突,该操作叫做 “同步主仓库”,组长的仓库就是主仓库。

提 PR、合并 PR 只能在 GitHub 页面上操作。同步主仓库是要用 Git 操作的。现在回到实验环境中操作。首先,使用 remote 系列命令来增加一个关联主机,执行 git remote add [主机名] [主仓库的地址],注意,主仓库的地址使用 https 开头的:

7212994-72612ea770250e3e.png
513.png

如上图所示,主机名是随意定义的,只要不是 origin 就可以,因为自己的仓库地址对应的主机名是 origin,主仓库的主机名通常定义为 up 或 upstream,这个主机名其实就是一个变量,它的值就是仓库地址,例如 git push origin master 完全等于 git push [email protected]:Manchangdx/work master

如此说来,关联主仓库后也没什么变化嘛,确实如此,即使地址写错也不会报出来。现在可以使用前面课程介绍过的 fetch 命令来拉取主仓库的全部分支信息到本地仓库了,我有时使用这个命令看上一个命令是否有拼写错误:

7212994-4553c24e53445073.png
514.png
7212994-46591a4a991a9090.png
515.png

如何同步主仓库哩?方法有二,一是执行 git pull --rebase up master ,此命令需联网,二是执行 git rebase up/stream,此命令不联网,因为前面已经执行了 git fetch up 这个需要联网的命令,本地已经有了最新的主仓库 master 分支信息,所以可以这么操作:

7212994-f7c5dc8853a18a11.png
516.png
7212994-d941c075d5893289.png
517.png

同步主仓库已完成。现在可以继续修改提交自己的 master 分支了。然后一并推送到自己的远程仓库。

猜你喜欢

转载自blog.csdn.net/weixin_34220179/article/details/86839175