Git与Github入门实践（下）

Git与GitHub入门实践（实验楼）学习笔记
学习网址：https://www.lanqiao.cn/courses/1035

一. 多人协作Github部分

本节将介绍 GitHub 多人协作与相关 Git 的操作，所有操作全部在浏览器页面上完成，内容相对较少。
建议大家准备两个浏览器和两个 GitHub 账号以便模拟场景。我的账号 Chuntianlaile 是一个用来测试的账号，假定这是项目组长的账号，Manchangdx 是组员的账号。

（一）创建仓库

首先，在组长账号中创建一个仓库，名为 work，在创建仓库时，需要说明第一节中提到的两个下拉框：

左边的忽略文件下拉框：我们在写代码时，总会出现一些不需要上传到仓库的垃圾文件、缓存文件、备份文件、环境文件等等，可以创建一个忽略文件将这些不需要被上传到远程仓库的文件忽略掉。忽略文件的名字是 .gitignore，它被放置在仓库主目录下，将不需上传的文件的名字写入其中，Git 就会自动忽略它们。比如这个仓库是用来 Windows 开发的，就在下拉框中选择 Windows，如果这是一个保存 Java 项目的仓库，就选择 Java。这样，在仓库创建成功后，忽略文件就自动出现了，这个忽略文件中有对应的语言或工具中绝大部分通用的忽略规则。当然了，你也可以自己手动增删改。

如果在创建仓库时忘记了选择忽略文件，几个提交后突然想起来，怎么办？GitHub 上有人把忽略文件都做好了，打开链接 github / gitignore ，这个仓库里有很多忽略文件，选择你需要的放到自己的仓库即可。

右边的开源许可下拉框：关于开源许可证，不属于本课程所述范围，如有需要大家可以自行搜索。我们的仓库不需要选择这一项。选择这个之后，仓库中会出现相对应的图标，比如上面提到的忽略文件仓库：

在组长账号中创建好新仓库，如下图：

对上图右上角三个按钮进行说明：
Watch：这是一个下拉按钮，可以选择对此仓库关注、不关注、忽略等。
Star：如果觉得这个仓库很好，就点击这个按钮送一颗星，在淘宝提供刷星业务之前，仓库获得的星越多表示该项目越优秀。
Fork：在别人的仓库中点此按钮会克隆一个完全一样的仓库到你自己的账号中，包括所有分支、提交等，但不会克隆 issue（本节后面会讲到），当此仓库发生版本变化，不会自动同步到你克隆的仓库里，反之亦然。

（二）添加合作者

现在在组长账号中增加该仓库的合作者，也就是组员：

在浅蓝色输入框中写入组员 GitHub 账号的用户名，选择正确的用户，点击右侧按钮就会发送一封邀请邮件给组员：

现在使用另一个浏览器登录组员的 GitHub 账号和邮箱，打开邮件：

点击上图绿色按钮，跳转到下图：

再次点击绿色按钮接受邀请，会跳转到组员访问组长仓库的页面：

点击上图紫色框中的 Fork 按钮，克隆组长的仓库到组员的账号中，完成后自动跳转到下图页面，也就是组员的仓库页面：

（三）添加 issue

切换到组长的 GitHub 页面，在仓库中添加一些项目任务或待解决问题，这些任务就是 issue：

写好任务标题后，可以在右侧指派一位或多位项目参与者来完成，同样 GitHub 也会给被指派者发邮件的（可以在自己的 GitHub 账号上设置拒收哪类邮件）：

写好两个 issue，前面说过的，组长仓库里的 issue 不会出现在组员仓库中：

二. 多人协作Git部分

（一）克隆仓库到本地

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

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

（二）完成任务并推送到自己的仓库

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

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


注意在执行 commit 命令时，备注信息里有个 “fix #1”，这是必要的，当备注信息中含有此字样的 commit 出现在组长仓库，仓库中编号为 #1 的 issue 就会自动关闭。类似的字样还有 “fixes #xxx、fixed #xxx、closes #xxx、close #xxx、closed #xxx”，这些并不重要，选择字母最少的 fix 就可以了。当然偶尔忘记写这个字样也不要紧的，issue 可以手动关闭，甚至关掉的 issue 还能再开。
完成以上操作，组员的 GitHub 仓库会发生变化，新增一个版本号为 b374 的提交：

(三）提 PR &检查合并 PR

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

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

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

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

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

该页面只有参与项目协作的成员有权限进入，当前 GitHub 的登录用户是组员，所以可见，且对这个仓库有完全的管理权限，除了删除仓库。当然了，检查合并 PR 的权限也是有的。重要的一点：提了 PR 之后，一定要求参与项目的其他成员来检查合并，不要自己来，尽管自己有权限。
上图中绿色按钮是个下拉按钮，合并 PR 的方法有三种，分别解释一下：
Create a merge commit ：这种方式会在组长仓库的 master 分支上生成一个新的提交，且保留 PR 中的所有提交信息。这是一种常规操作，用得最多。
Squash and merge ：压缩合并，它会把 PR 中的全部提交压缩成一个。此方法的优点就是让提交列表特别整洁。一个 PR 里有很多提交，每个提交都是很细小的改动，保留这些提交没什么意义，这种情况就使用此方法合并 PR。
Rebase and merge ：这种方法不会生成新的提交，例如 PR 中有 6 个提交，用此方法合并后，组长仓库也会新增 6 个提交。注意，这些提交的版本号与组员的提交不同，此外完全一样。
现在切换到另一个登录组长账号的浏览器，打开合并 PR 的页面，用第一种方法合并：

这就是第一种方式合并的结果，生成了一个新的提交，这个提交里没有修改。因为样子不太美观，这是我最不喜欢用的方式。仔细看上图的 issue，变成了 1 个，也就是说在合并 PR 后，#1 issue 被关闭了。
以上就是一次完整的修改、提交、推送、提 PR、合并 PR 的过程。
需要注意的一点：从 A 向 B 提 PR 后，在 PR 合并或关闭前，A 上所有新增的提交都会出现在 PR 里。

（四）同步主仓库

因为组长的 master 分支新增了一个空提交，所以需要让组员的仓库同步组长的仓库，使它们的提交版本一致。作为组员，要时刻保持自己的 master 分支与组长的一致，以避免在下次提 PR 时出现冲突，该操作叫做 “同步主仓库”，组长的仓库就是主仓库。
提 PR、合并 PR 只能在 GitHub 页面上操作。同步主仓库是要用 Git 操作的。首先，使用 remote 系列命令来增加一个关联主机，执行 git remote add [主机名] [主仓库的地址]，注意，主仓库的地址使用 https 开头的：

如上图所示，主机名是随意定义的，只要不是 origin 就可以，因为自己的仓库地址对应的主机名是 origin，主仓库的主机名通常定义为 up 或 upstream，这个主机名其实就是一个变量，它的值就是仓库地址，例如 git push origin master 完全等于 git push git@github.com:Manchangdx/work master 。
如此说来，关联主仓库后也没什么变化嘛，确实如此，即使地址写错也不会报出来。现在可以使用前面课程介绍过的 fetch 命令来拉取主仓库的全部分支信息到本地仓库了，我有时使用这个命令看上一个命令是否有拼写错误：


如何同步主仓库哩？方法有二，一是执行 git pull --rebase up master ，此命令需联网，二是执行 git rebase up/master，此命令不联网，因为前面已经执行了 git fetch up 这个需要联网的命令，本地已经有了最新的主仓库 master 分支信息，所以可以这么操作。
总结一下：git pull --rebase = git fetch + git rebase。现在使用方法二来同步：

同步主仓库已完成。现在可以继续修改提交自己的 master 分支了。然后一并推送到自己的远程仓库。
以上是在自己 Fork 的仓库里进行修改的过程。还有一种常用的方式，就是不用 Fork，直接克隆组长的仓库到本地，然后各自创建自己的分支，在自己的分支上进行修改提交，最后从自己的分支向 master 分支提 PR。方式不同，原理一样。
关于多人协作的 Git 操作就到这里了。

三. Git tag 和 GitHub releases

（一）Git标签的作用

在一个项目中，我们可能需要阶段性地发布一个版本，比如 $V1.0$、$V1.0.2$、$V3.2Beta$之类的，Git 的标签可以满足这个需求。在一个长期大型项目中，可能会有数千个提交版本，我们可能需要对重要的节点性提交打个记号，这时也可以使用 Git 的标签功能。在一些项目相关的书籍中，我们会看到 “执行 xxx 命令签出这个版本以查看对应的代码” ，这也是使用 Git 的标签功能做到的。本节将详细讲解此功能的具体操作。

创建标签

前面的课程提到过 GitHub 的 issue 功能，issue 是仓库拥有者在 GitHub 上手动创建的，仓库被 Fork 时 issue 不会跟随。Tags 通常在本地使用 git 命令创建后推送到 GitHub 上，与 issue 相同的一点，它也只存在于项目仓库内，Fork 或提 PR 都不会带上它。在多人协作项目中，通常由组长对主仓库设置 Tags，单人项目自然就是自己说了算。
开始操作。首先，克隆仓库、配置信息、查看提交版本历史：

重要的一点，我们创建标签是给具体的某次提交创建的，跟分支无关。创建标签使用 git tag [标签名] -m [备注信息] [提交版本号] 这个命令。其中 -m [备注信息] 可以省略不写，但建议不要省略。[提交版本号] 可以省略，如果是给当前分支最新的提交创建标签的话。
给当前分支当前版本创建一个标签：

这样一个本地标签就创建完成了。

查看标签

执行 git tag 命令显示仓库中的全部标签列表，执行 git show [标签名] 查看标签详情：

前文已提到，标签是在提交的基础上创建的，如果仓库的多个分支中都有这个提交版本，那么这些分支上就有关于这个提交的相同的标签。

删除本地标签

当我们执行 git tag [标签名] 创建本地标签后，在仓库主目录的 .git/refs/tags 目录下就会生成一个标签文件：

执行 git tag -d [标签名] 删除本地标签，标签文件也会被删除：

将本地标签推送到远程仓库

首先对两个提交版本创建对应的标签：

执行 git push origin [标签名] 推送标签到远程仓库，注意前面的命令都只涉及本地操作不需要联网，此命令需要联网：

我们到浏览器上打开仓库主目录，点击下图红色框可以查看 releases 和 tags ：

点 Tags 按钮查看标签：

关于 releases 是什么，下文会介绍。
如果你一口气创建了 6 个标签，当然啦，这种情况很少发生，可以使用 git push origin --tags 命令将全部本地标签推送至远程仓库：

查看远程仓库情况：

删除远程仓库标签

如果标签废弃不用或者写错了，可以使用 git push origin :refs/tags/[标签名] 删除远程仓库的标签，命令中的标签名其实也就是文件名：

再次查看远程仓库：

好，删除成功。以上就是关于 Git 标签的创建、查看、推送、删除的操作流程。
查看本地仓库的标签列表：

咦，001 标签还在呢？是的，本地标签需要另外手动删除，上文已演示。

签出版本

现在介绍一下关于 “签出版本” 的操作，我们会见到类似这种说明：“如果你从 GitHub 上克隆了这个程序的仓库，那么可以在仓库主目录下执行 git checkout xxx 签出程序的这个版本。” 其实签出版本就是指定某个提交版本创建一个新的分支。
假定当前的 work 仓库就是一个程序，我们要签出 001 版本，执行以下步骤即可。
首先执行 git checkout [标签名] 切换到之前的某个提交版本，然后执行 git checkout -b [新的分支名] 将此提交版本固定到一个新分支上并切换到此分支：

这样就利用标签完成了提交版本签出的工作。

（二）GitHub 的 releases

GitHub 的 releases 是 2013 年发布的新功能，旨在协助软件开发者分发新版本给用户，关于这个功能这里仅作简单介绍。

当项目组织宣布发布一个软件产品的版本，发布过程就是一个将软件交付给最终用户的工作流。版本是具有修改日志和二进制文件的一类对象，它们提供了 Git 工作流之外的完整项目历史，它们也可以从存储库的主页上被访问。发布版 release 附带发布说明和下载软件或源代码的链接。按照许多 Git 项目的约定，发布版本与 Git 的标签 tag 绑定。您可以使用现有的标签，或者让 release 在发布时创建标签。这就是上面查看 GitHub 仓库中标签信息时出现的场景。

标签是 Git 中的概念，而 releases 则是 Github、码云等源码托管商所提供的更高层的概念。Git 本身是没有 releases 这个概念，只有 tag。两者之间的关系则是，release 基于 tag，为 tag 添加更丰富的信息，一般是编译好的文件。