和傻子一起写代码

UP主: HDAlex_John · 时长: 31:09 · 🔗 B站原视频

标签: Git · GitHub · VS Code · 多人协作 · 编程开发

准备工作与环境配置

Hi，这里是 ALEX。今天我就带各位简单地学习一下，该怎样和我们的呆瓜实习生一起来协作。

在开始之前，希望你自己已经知道了该怎样使用 Git 和 GitHub，以及管理你自己本地的项目，并将它发布到你自己的 GitHub 账户上。如果你不知道该怎么做，没关系，你可以看一下视频中间弹出的链接，我之前有做过相应的视频。

开始之前，需要保证你自己的电脑上有安装好 Git，并且有使用到 VS Code。我在这个视频中，会使用 VS Code 自带的工具来带你学习，怎样使用 VS Code 和 GitHub 实现代码的多人协作。当然这里我只演示两个人。

同时，在我们的呆瓜实习生的电脑上，他也需要自己注册一个 GitHub 的账户，并且要安装上 Visual Studio Code。这里一定要注意，你的 VS Code 一定要是最新版，也就是保证左边有这样一个源代码管理的功能。同时还一定要保证你的 VS Code 编辑器里，一定要登录好对应的 GitHub 账户，不然待会的操作可能会和我有一些出入。

如果这些你都没做的话，还是希望你像我刚才说的那样，去找到之前的视频，看一下我之前所做的内容，确保你已经完成了相应的设置。

本地项目发布与 .gitignore 配置

开始之前，我们重复一下之前我所做的步骤，那就是把我们自己本地写好的项目，发布到我们 GitHub 自己的页面上，或者说自己的个人仓库中。

发布之前，请你一定要写好一个文件，它叫做 .gitignore。这个文件就是设置我们在推送本地项目的时候，有哪些文件夹或文件，把它从推送的名单中排除出去。

什么意思呢？可以看到我现在写的是一个前端项目，前端项目必不可少地会使用到一个叫做 node_modules 的项目依赖。项目依赖本身其实是没有必要把它放在 GitHub 上的，因为它本来就很大，而且里面的文件非常多、非常杂，完全没有必要把它放上去。因为我们只需要知道我们这个项目用了哪些依赖就可以了，在用到它的时候安装一下就行了，没有必要把安装好的这些文件也给它放上去。

所以我们要在这个文件中写上这样一些排除的配置。而且注意这个文件名一定不要写错，叫做 .gitignore。如果这个文件名你写错一点，在我 VS Code 文件图标主题下面，它都是会变样子的。一定要保证好你的文件名是写对的，这样左边的文件图标才是正确的。

初始化本地仓库与链接远程仓库

写好这个部分之后，我们来到 VS Code 左边的源代码管理。只要你是安装了最新版的 VS Code，并且你在电脑上有安装好 Git，那么你对应的左边展示的内容应该是和我一模一样的。

首先，我们先创建这样一个简单的本地 Git 仓库。点击初始化仓库，然后在这里输入这次提交的内容“初始化提交”，提交。在下面这个 Graph 这里就出现了我们的提交记录。如果你没有下面的 Graph 怎么办呢？在 Source Control 右边这三个点点一下，下面选择你想要使用的内容，我们这里只需要 Changes 和 Graph 这两个东西就可以了，如果你没有的话就把它勾选上。

做完这两步之后，我们需要在我们的 GitHub 账户上面新建一个仓库。这个仓库我们先设置成私有，这里我就叫 git-collaborations。下面这里千万不要点，我在做之前的教程的时候，发现有些同学手欠把这些东西点了一下，导致你自己本地的代码没有办法成功推送到远程的 GitHub 仓库上。有极大原因就是因为你自己在这里点了一些新的文件，导致本地和远程产生了冲突，所以推送不上去。所以这里一定不要手欠。创建我们的仓库，创建完成之后，这里我们就不用管了。

回到我们的 VS Code，我们用 VS Code 的图形化工具来给它指定对应的远程仓库。来到左边的源代码管理，在上面 Changes 这里点这三个点，下面有一个 Remote（远程），添加远程。上面会展示我们可以手动输入 GitHub 这个仓库的链接，但是我个人不推荐这样做。因为我们只要配置好了网络代理，直接选择这里的“从 GitHub 添加远程”就可以了。点击它会自动加载我们这个 GitHub 账号下面所有的仓库，不管是私有还是公有。这里我们就可以找到最近的这个 git-collaborations，点击。

然后这里要设置一下这个远程仓库的名字。这个名字是用来干什么的呢？很多人会问到，这个就是用来区别当你一个本地的仓库对应多个远程仓库的时候，比如你可以把它推送到 GitHub 或者是 GitLab，又或者说 Bitbucket。那你作为一个本地仓库该怎样区别你添加了多个远程仓库呢？区别的依据就是这里我们所输入的远程仓库的名字。我个人的习惯是，我链接到哪个远程仓库，就输入这个远程仓库对应的平台的名字，比如这里的 GitHub。当然我们也可以把同一套代码推送到同一个平台上的不同的远程仓库上，这时候可能就需要在后面加上一些后缀，比如 public、private。这里我就输入 GitHub 就可以了，回车。

这一步仅仅是把我们的本地仓库和远程仓库链接起来，我们还没有推送。点一下这个 Publish Branch 进行推送就可以了。因为我之前有做过推送的操作，所以中间这里没有任何的提示，我们就已经完成了。下面的 Graph 就同时出现了我们本地的进度和远程的进度，就是这里，有一片云，还有类似靶子一样的东西，指示我们本地的进度和远程的进度保持了一致。回到我们这个仓库刷新一下，我们就能够看到我们这里的代码。需要注意这个仓库它是私有化的，你在网络上是搜不到的。

添加协作者与克隆仓库

接下来我们就要把我们的呆瓜实习生添加到我们这个仓库中，让他作为其中一个作者和我们一起协作开发。

首先来到这个仓库中，最右边这里的设置。在设置这里，在左边找到 Access 下面的 Collaborators（协作者），我们添加一个协作者。这里你可以输入这个呆瓜实习生对应的 GitHub 账户的邮箱，或者是对应的 GitHub 的名字。我个人还是更推荐使用邮箱。我们去找一下这个实习生他的邮箱，直接在设置里找，左边找到 Emails，这就是他的邮箱。我这里是虚拟机复制不过来，我就手写了。然后发送这样一个邀请。下面就会展示这样一个邀请，并且对应这个邮箱地址的 GitHub 账户的名字，你可以看一下有没有邀请错，如果拉错人了，就把它删掉。

我们在实习生的这个页面稍微多等待一会儿，稍微刷新一下。可以看到右上角这个跟抽屉一样的部分，就是我们 GitHub 上的通知栏，你可以把它比作一个收件箱。我们点开，这里就有一个通知了。在这个地方我们把它点开，这里我们就可以直接点击 Accept Invitation 接受这个邀请，这样我们就可以直接访问到这个仓库了。

因为这个仓库是私有的，虽然我们作为实习生已经进入了这个仓库，但是在实习生的视角下，如果他打开自己的仓库列表，他是看不到这个项目的。那要重新进入这个页面该怎么做呢？其实很简单，同样来到设置，左边找到这里的 Repositories，也就是所有仓库，这里就可以找到和其他人相关的这个仓库，就是刚才我们邀请进来的，我们重新点击一下就能回到这里了。

实习生想要工作，肯定是要把我们刚才上传上去的代码拉到他自己的电脑上，然后尝试先跑一下。你肯定要先跑一下，了解一下这个项目，才能够知道该怎样去修改它。这里该怎么做呢？其实很简单，我们不需要手动输入 Git 命令，也不需要复制这里的链接。直接来到实习生电脑上的 Visual Studio Code，同样打开左边的源代码管理，点击这里的克隆仓库。这里稍微放大一点，这里就有一个“从 GitHub 克隆”。使用这个按钮的前提，就是实习生的电脑上自己就已经链接到了他自己的 GitHub 账户上，这里是一个登录好的状态，一定要确保这一点。然后点击克隆仓库，从 GitHub 克隆。此时它就会展示他所加入的所有的 GitHub 仓库。前面的这些前缀是他自己的账户，那就说明这个仓库是他自己的；前面的前缀是我们自己的名字，就说明这是我们刚才拉他进来的共同协作的项目。点击这个仓库，我们会选择一个位置去存放这个项目，我们就放在桌面吧。这里克隆的速度如果很慢，说明你没有设置 Git 的网络代理，你需要简单设置一下代理。我们打开这个克隆仓库。

模拟协作与代码同步

可以看到效果和我们刚才自己电脑上是一样的。我们可以尝试跑一下，这是一个前端项目，各位如果会前端的话可以跟着跑一下，这不是本节的重点。我们先进入这个 front-react 安装依赖，尝试着运行。这就是我们这个项目的前端应用，它长得这个样子。

那我们这个实习生接下来就要搞一点怪了。他觉得上面这个 server is down 这个组件，或者说这个前端页面上的内容不是很好看，要求给它删掉。我们的前端小呆瓜小白就来到对应的地方，先给它停止运行，把这个地方自作聪明地给它删掉，保存一下。

保存完之后，我们要进行推送。来到左边的源代码管理，写上这次推送的名字，我们的呆瓜实习生就自以为去掉了这样一个组件，写上 Remove status component，在本地提交这次修改，然后同步更新到我们的远程仓库上。点击。下面可以看到它已经同步上去了，这里的云已经更新到了实习生写好的最新版本中。我们来到 GitHub 仓库刷新一下，可以看到这里就更新到了刚才实习生写的版本。

我们回到我们自己的视角下，来到这个仓库内容，可以看到这里的版本已经更新过去了，也就是在 src/components 下面的这个 App.tsx。这就是刚才我们实习生留的痕迹，上面还写上了他刚才写的这次提交的一些描述。

那在我们自己的电脑上，该怎样同步这次的修改呢？其实很简单，来到源代码管理，在 Graph 右边有三个长得很像的按钮，我们点击最左边这一个，它就是从所有的远程去获取对应的更新。因为我们这里只有一个远程仓库，所以我们点击这个按钮就可以了。点一下，此时可以看到我们这里就更新到了这个版本。但是这个版本只是将远程仓库的版本拉取了下来，我们本地代码的版本还没有更新到这个地方去。那该怎么做呢？其实也很简单，在左边这个按钮的右边，第二个按钮 Pull 这个地方我们再点一下，这样我们自己的电脑上也同步到了这个版本。这样我们自己的代码版本就和我们的呆瓜实习生同步了。

可以看到这里他添加了这个像注释又不像注释的东西就写了进来。但很明显这个写法明明是错误的，我们正确的注释应该是这样写。我们这个实习生好像连快捷键都不会用，他竟然写错了，连一个简单的注释他都写错了。

配置分支保护规则 (Branch Rulesets)

可以看到在整个协作过程中，我们的实习生在没有经过我们允许之下，就直接将代码的修改推送到了仓库中。如果我们的仓库链接到了一些 CI/CD 工具，那么这个 CI/CD 工具就直接基于实习生写的这个版本进行了部署。这样一部署肯定就出错了。为了避免我们的呆瓜实习生写一些错误的代码，在没有经过任何人检查的情况下就直接影响到生产环境，我们肯定要对仓库的代码推送做一些限制。也就是在他推送代码之前，需要我们进行简单的 Review，也就是代码审查。

这个设置该怎么做呢？同样来到仓库这里的设置，在左边找到 Rules，也就是 Code and automation 下面找到 Rules，这上面有个 Rulesets。我们新建一个 Ruleset，这里它下面有三个选项，我们就选择第一个新建一个分支的 Ruleset。首先是这个规则的名字，我们就叫 main，这里随便起都可以。然后是它的状态，现在是禁用的状态，我们要给它设置成启用。这里的 Bypass list 我们用不到。下面的 Target branch，我们就一定要给它设置成我们所需要限定的分支，或者说所需要限定的目标。而这里的这个分支或者说目标，其实就指代我们代码的主分支。如果你没有代码主分支的概念，你可以回看一下我们这个代码仓库，可以看到这里我们只有一个 Branch（分支），它的名字叫做 main。

所以我们再回到这里的设置，Rules -> Rulesets，新建一个 Ruleset，启用。在下面 Target 这里，你可以直接选择 Include default branch，这里的 default branch 就是默认分支的意思，我们的默认分支就是刚才的 main 主分支，你可以直接点击它。但如果你要是给其他的分支设定相应的规则，你就需要在下面 Include by pattern，也就是通过一些规则匹配来设置我们的分支。这里其实很简单，我们直接写上我们需要设置相应规则的分支的名字就可以了，添加。这就是它所影响到的分支的名字。

接下来是下面具体的规则。这里的规则很多，但我需要各位照着我做的只有这么几个。上面这些都不用看，我们只需要这个 Require a pull request before merging，也就是在合并代码之前需要创建一个 Pull Request。它是什么意思？我们先把它点开。可以看到下面给了一些简单的注释，这里内容很长，我就简单用一句话告诉各位。它的意思就是我们不能像刚才那样直接操作。刚才我们那样的直接操作，就是我们想要更新代码到主分支上，就直接把对应的更新推送了上来，就像刚才的实习生所做的，直接点了提交，然后就直接在我们的 GitHub 仓库上面生效了，中间没有任何的审查过程。

我们勾选了这个按钮之后，就不能够直接这样做。我们需要先创建一个新的分支，把我们所做的修改提交到这个新的分支之后，再由这个新的分支合并到我们自己的主分支中。听起来很抽象，没关系，你先跟着我这样设置，待会我们再来讲具体是怎样做的。这里有一个 Required approvals，也就是设置这次修改需要几个人看了之后才能够批准。这里我们最少选择 1，不然你选择 0 的话，别人没看就可以直接批准，那还有什么意义呢？我们选择 1。接下来的这些操作我们先不管，就这样，我们直接 Create 创建。

这里它就警告我们了：“Your rulesets won't be enforced on this private repository until you move to GitHub Team/Organization account”。它告诉我们，这个规则在一个私有的仓库中是没有办法生效的，除非我们升级到 GitHub 的团队组织账户。我们点一下升级按钮，看看会发生什么事情。首先它需要选择我们要给哪些仓库升级到这个组织下，然后它告诉我们这个 GitHub Team 需要花费 4 美元每月。所以这个功能如果针对私有化仓库是付费的。为了达成我们今天的效果，我们先要把这个私有仓库修改成一个公开的仓库。怎么修改呢？来到这里的 General（通用），滑到最下面，可以看到这四五个按钮都是红色的，说明这些操作是比较危险的。我们点最上面这个 Change visibility，也就是修改它的可见性，我们将它设置为公有。修改完成，我们再来到刚才的 Rules -> Rulesets，重新设置一下。刚才规则已经保存了，这个规则现在应该是已经生效了。

通过 Pull Request 提交与审查代码

生效之后，我们再来看一下刚才这个呆瓜实习生的操作还能不能再次生效。我们这个呆瓜实习生发现自己写错了，把这里的内容改一下，假装好像什么事情都没发生一样。然后这里的消息就写 fix my fault，提交，然后同步更改。他以为这样做就万事大吉了，结果发现刚才明明还可以直接推送上去的，但这里就提示有问题，没有办法直接推送。我们可以在这里点击显示命令输出，看一下 Git 的解释是怎样的。它告诉我们这里有 Repository rule violation found，根据仓库的一些规则，我们这个操作是没有办法生效的。它告诉我们 Changes must be made through a pull request，这里的修改必须通过一个 Pull Request 的请求才能够生效，而不能直接这样推送上去。那我们实习生傻眼了，该怎么做呢？

这里就需要像我刚才所说的那样，先创建一个分支。但是我们本地的部分已经写成这样了，没关系，我们在 VS Code 的左下角找到这个分支 main，点一下，创建一个新的分支。这里我推荐用一些开头，比如 feature 的缩写 feat，然后写上用户的名字，回车。我们就创建了一个分支。如果你不知道你现在位于哪个分支下，同样在左下角都可以看到，你也可以随时切换回来，比如切换到 main，我们又回来了。再回到这个 feature 分支，在这个分支下，我们直接点击发布，因为这个分支的内容已经保存了。因为这个分支是基于刚才的 main 分支进行创建的，创建的内容和 main 分支的内容是一模一样的。所以我们想要把修改通过新创建的分支发布上去，点击发布。这个发布是没有任何阻碍的，可以看到成功了。

但是这个新的分支所提交的功能，它并不会影响到主分支。什么意思呢？我们刷新一下。可以看到仓库页面下，首先它变成了一个公有的，其次下面这里的分支就多了一个，就是刚才所创建的分支的名字。但是刚才这个新的分支下所做的修改，名字叫 fix my fault，后面的名字就是呆瓜实习生的名字。可以看到这个修改并没有作用到我们的 main 主分支下，但是我切换到实习生的分支，可以看到它是作用在了这个地方，这里有一个简单的注释。

那我想要做的就是提交这样一个请求，请求将我们这个分支中的修改内容合并到主分支中。这里该怎么做呢？GitHub 其实已经提示我们了，它提示这个分支在 54 秒之前已经被推送了上来，然后提示我们要创建一个 PR。PR 就是 Pull Request 的意思，其实就是一个合并的请求。我们要点击这个按钮，或者在没有这个按钮的情况下，直接在这个项目上找到 Pull requests，然后新建一个 Pull request 就可以了。当然这里我就图方便点一下这个按钮。点一下这个按钮之后，注意上面我们要看到这里的箭头和对应的分支名字是否一致。我们要做的是从新创建出来的分支，将它的内容合并到主分支中。所以左边是我们的 main，右边是 feature 加上实习生的名字，这个分支一定不要搞错了。

我们来写对应的合并请求的内容。首先是 Title（标题），下面是描述。描述这里使用了 Markdown 语法，你可以往里面添加一些图片和链接，我就不再做解释了。我们直接创建这样一个合并请求。创建完成，这里的合并请求下面的状态是 Open，也就是还并没有被合并进去的状态。

那实习生能不能自己把这个请求合并进去呢？很明显这个按钮它是不可用的，是没有办法合并进去的。因为我们需要一个人来进行审查，也就是这个地方提示的：At least one approving review is required by reviewers with write access。也就是至少需要一个有写权限的审查人员来审查之后才能够进行合并。虽然笨蛋实习生自己有写的权限，但是刚才的设置中其实排除了自己审查自己合并的能力。所以虽然我们可以在 Files changed 这个地方（也就是文件对应的修改内容），对自己的修改内容进行简单的审查，点一下这个按钮，我们只能够简单地进行评论，但是并不能够通过。也就是下面 Approve 这个选项我们是没有办法选中的，它直接告诉我们：Pull request authors can't approve their own pull request。也就是这个 PR 请求的作者并不能够批准自己发出的请求，我们需要另一个人来批准才可以。我们这里就简单写上对应的评价或者评论：“I think it's good”，在下面添加这个简单的审查评论。但是可以看到这个按钮依然是不可用的。

回到我们自己的视角下，刷新一下仓库，可以看到这里的 Pull requests 就多了一个简单的气泡提醒。并且我们的通知收件箱就多了一个通知，我们点一下，它就提示笨蛋实习生发起了一次合并请求。点进去，可以看到笨蛋实习生觉得自己写的没问题，但是他没办法合并，我们自己也没办法合并，因为我们还没看对应的请求到底写得怎么样。来到 Files changed 看一下他写得怎么样，他把错误修改回来了，没问题。点击 Review changes 审查，给这个请求批准：“Ok, it's fine”。批准之后，我们才能够点击合并请求按钮。点一下，这里要写上这次合并的标题以及对应的合并描述 Fix intern fault，确认我们的这次合并。此时这个合并请求的状态就变成了 Merged。

我们再回到项目的首页，可以看到上面的气泡就消失了，因为合并请求已经被处理掉了。因为我是从收件箱（通知栏）进来的，所以上面会有一个简单的和通知栏有关的状态，提示问题是否解决了。如果解决的话，我们就可以点击 Done。解决掉之后，这个信息就会被收折起来，就不会打扰我们了。

再回到项目，此时主分支中的代码就合并了刚才笨蛋实习生提交的内容。但如果每次都这样做，分支的数量会变得非常多。合并之后，实习生的分支就没用了，我们可以直接删掉。这里该怎么做呢？直接点一下分支的展开栏，点击下面的 View all branches（查看所有分支），把笨蛋实习生的分支删掉就可以了。这样就只剩下一个分支了，看着比较清爽了。

但是，是不是把笨蛋实习生的分支删掉之后，他犯的错误就消失了呢？当然不是的。回到我们的视角下，来到源代码管理，参照之前的操作，同步一下远程仓库的内容，再同步一下当前的进度。同步之后，可以看到这里面很明显多了一个分支，这个分支就是笨蛋实习生创建的，名字都不一样。我们所做的操作就只有初始化和最后合并这两步，笨蛋实习生留下的愚蠢操作还是会被保留下来的。虽然把他的分支删掉了，但是记录还是在的，我们并没有把记录删掉。

管理员权限与规则绕过

这里其实有一个问题，就是我们在知道自己的代码没有写出任何问题的情况下，直接在没有其他人审查的情况下更改当前的主分支，是否可行呢？其实也是不可行的。我们可以来试一下，我们就给笨蛋实习生擦屁股，把这里的组件注释掉。我们自己来尝试提交 remove the status component via comment，然后尝试去同步这次的修改，也就是直接更改到主分支上面。点击可以看到，出现的错误提示和刚才的笨蛋实习生是一模一样的。说明当我们自己设置这个规则之后，我们也依然需要通过刚才的操作形式，创建一个新的分支，上传到 GitHub 仓库中，再由其他人去审查代码更改，审查之后才能够合并到主分支上。

但问题是这个仓库就是我自己建的，我就是这个项目的负责人，我自己应该是不受限于这些规则的。理是这样说没错，那难道 GitHub 作为一个运营这么久的平台，连这点问题都没有考虑到吗？其实是有考虑到的。只不过这个功能和刚才我们在私有化仓库中尝试制定限制是一样的，这个功能也仅限于 GitHub Teams 团队项目中才是可行的。我们首先要把这个项目添加到一个组织下，而创建一个组织，就是和我刚才说的一样，需要给 GitHub 每个月交 4 美元的费用，才能够升级账户、创建对应的组织、拥有这样一些新的设置。

所以如果我们想要保留当前的规则，还想要直接把代码合并到主分支下，而不经由其他任何人审查，目前来看是不可行的。但是我们可以走一下捷径，毕竟这个规则是我们自己定的，所以我们可以简单地把这个规则禁用一下。比如来到 Rulesets，点进这个规则进行编辑，把状态设置为 Disabled，简单禁用一下，保存。再回到编辑器进行同步，这样就很简单，我们就直接修改了主分支。然后再把这里的状态启用起来，保存。这样笨蛋实习生就提交不进来了，我的代码就直接进入了主分支。

总结

到此我就简单给各位看了一下，如何通过 VS Code 和 GitHub 实现协同管理同一个代码仓库的过程。

这里的重点就是，我们在和其他人协作，尤其是在你不是很信任协作者、带一些笨蛋实习生的时候，一定一定要注意，要给仓库设置对应的推送规则。在他推送之前，一定需要他自己创建一个新的分支，然后让他自己尝试去发起一个将新分支中的更改合并到主分支的请求。这个请求需要你自己去查看，并且 Review 之后才能够合并。也就是刚才我们所做的这个地方，因为请求已经关闭了所以看不到，我们可以把上面的状态删掉回车，就可以看到刚才已经合并进去的修改了。我们一定要像刚才所做的这样，来到 Files changed 进行简单的代码审查，然后才能够点击合并按钮，将代码内容提交进去。

这就是一个简单的流程。以上就是本期视频的所有内容，希望你能关注或订阅我的频道。感谢你的观看，我们下期视频再见。