(5)多人协作Git部分——学习笔记

1. 克隆仓库到本地

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

链接的结尾 .git 是不需要的&＃xff1a;

2. 完成任务并推送到自己的仓库

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

创建文件&＃xff0c;添加到暂存区&＃xff0c;提交&＃xff0c;查看本地仓库分支状态&＃xff1a;

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

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

3. 提 PR & 检查合并 PR

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

好&＃xff0c;现在我们从组员的 work 仓库 master 分支给组长的 work 仓库 master 分支提一个 PR&＃xff1a;

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

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

完成后&＃xff0c;页面自动跳转到组长的 work 仓库 PR 的合并页面&＃xff1a;

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

上图中绿色按钮是个下拉按钮&＃xff0c;合并 PR 的方法有三种&＃xff0c;分别解释一下&＃xff1a;

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

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

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

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

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

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

需要注意的一点&＃xff1a;从 A 向 B 提 PR 后&＃xff0c;在 PR 合并或关闭前&＃xff0c;A 上所有新增的提交都会出现在 PR 里&＃xff01;&＃xff01;&＃xff01;

4. 同步主仓库

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

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

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

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


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

总结一下&＃xff1a;git pull --rebase &＃61; git fetch &＃43; git rebase。现在使用方法二来同步&＃xff1a;


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

以上是在自己 Fork 的仓库里进行修改的过程。还有一种常用的方式&＃xff0c;就是不用 Fork&＃xff0c;直接克隆组长的仓库到本地&＃xff0c;然后各自创建自己的分支&＃xff0c;在自己的分支上进行修改提交&＃xff0c;最后从自己的分支向 master 分支提 PR。方式不同&＃xff0c;原理一样。
参考&＃xff1a;实验楼