Git 和 GitHub：完整指南 - 第 8 章：协作

大家好，希望你们和我一样喜欢这个关于 Git 和 Github 的系列文章。不过，就像所有美好的事物一样，它终究会有结束。

最后一章花了很长时间才发布，我一直忙于学习，现在我很自豪地说我已经完成了我的 Microsoft 365 认证：基础知识。

可信度

我是一名 IT 技术人员，所以这个在我的工作场所真的很有用。😁

今天我们要讨论 GitHub 中最重要的主题之一，那就是协作。

在上一章中，我们学习了如何将他人的远程仓库复制到我们自己的 GitHub 帐户，以及如何将其克隆到本地计算机。我们进行了一些更改并更新，当我们对更改感到满意时，我们最终将其贡献给了原始所有者的远程仓库。

整个过程有点像合作，唯一的区别是它实际上不是！

在合作的情况下，所有者可以添加不同的开发人员作为合作者，每个合作者将拥有与所有者几乎相同的权利和权限，从而允许他们管理项目。

我们说几乎是因为可能制定了一些规则来管理赋予合作者的不同角色并保护主分支或其他分支。

我们将要讨论的内容：

• 添加合作者
• 成为合作者
• 保护你的分支

添加合作者

首先，我们将在本地计算机上创建一个新的存储库，具体方法是在桌面目录中创建一个文件夹，我们将这个新存储库命名为“collabs”。打开 VS-Code 并选择新创建的文件夹。

我们要做的第一件事是通过在“collabs”文件夹中运行以下命令来初始化存储库：

git init

然后我们创建两个文件，分别命名为 index.html 和 style.css。接下来，我们通过运行以下命令将它们添加到暂存区：

git add .

最后我们通过运行以下命令进行提交：

git commit -m 'created index.html and style.css'

让我们将我们的 html 结构添加到 index.html 文件并进行提交，然后向 index.html 文件添加 H1 标签并进行另一次提交。

我们继续修改 style.css 文件，添加项目变更。我们选中 html 页面中的所有元素，并将边距和填充设置为 0，然后进行提交。我们记录提交的历史记录，以查看进度。我们通过运行以下命令执行此操作：

git log --oneline

我们的历史记录中存在相当多的提交，接下来我们需要在 GitHub 上创建远程存储库并将我们的本地存储库推送到远程。

正如前几章所讨论的，我们可以将远程仓库的URL 链接添加到本地仓库，以将它们绑定在一起。我们通过运行以下命令来执行此操作。

git remote add origin

该命令后面跟着远程存储库的url链接。

最后，我们运行命令将本地仓库推送到远程仓库。我们使用以下命令：

git push origin master

你可能会遇到权限相关的错误。要修复此问题，你需要在控制面板中更改凭据（Windows 用户）。所有 Mac 用户都需要创建一个 SSH 密钥并将其添加到你的新 GitHub 帐户。就像我们在上一章中所做的那样。

在我们创建新 repo 的 Github 帐户上，您可以看到当我们刷新页面时，我们的本地存储库已成功推送到我们的远程存储库，包括所有文件和提交。

合作时机

为了将某人添加为我们项目的协作者，我们需要导航到“设置”选项卡。在“设置”选项卡中，屏幕左侧列出了我们可以管理的各种设置。

我们本质上想要实现的是让其他人访问我们的仓库。“管理访问权限”选项是我们进行访问权限管理的地方。在这里，我们可以看到与访问控制相关的各种管理设置，在下方，我们可以看到我们尚未邀请任何协作者。

我们可以选择“添加人员”按钮来添加合作者，将会弹出一个框，我们需要填写我们想要授予存储库访问权限的人员的全名、电子邮件地址或用户名。

找到并添加合作者后，请注意它显示“等待合作者回复”。这是因为合作者需要接受发送给他们的邀请。

你可能期望协作者的 Github 帐户会收到某种通知或消息。然而事实并非如此。😕

合作者将收到一封电子邮件，其中的消息大致是“此人想邀请您合作开展他们的 GitHub 项目”。

是否接受邀请取决于协作者。一旦协作者接受邀请，所有者的仓库将被拉取到协作者的 GitHub 帐户中。

在所有者帐户的“管理访问”选项中，我们将看到我们的存储库中添加了1 个新合作者。

成为合作者

我们已成功将合作者添加到我们的项目中，现在该合作者拥有完全访问权限并可以按照他们想要的方式管理代码。

我们可以模拟以协作者的身份处理此代码库。但是，为了正确模拟此过程，我们需要在另一台计算机上处​​理该项目，否则我们将得到意想不到的结果，这可能会让您感到困惑。

如果您有第二台电脑，可以用它操作第二个 GitHub 帐户。我使用 Azure 快速配置了一个虚拟机，可以模拟我的协作者身份。

首先，由于我们是合作者，我们不再需要分叉存储库，我们只需要将其克隆到我们的本地计算机。为此，我们可以单击url 链接来克隆存储库。

在 VS-CODE 中，我们需要在桌面目录中创建一个新文件夹。我们进入该文件夹，然后运行以下命令：

git clone 

此命令后面是我们从远程存储库获取的url 链接。

如果我们记录提交的历史记录，我们将看到在所有者本地存储库上所做的提交。

到目前为止，一切都很好！

现在让我们以合作者的身份对项目进行一些更改。

首先，我们将修改 h1 标签的大小，将字体大小增加 40px。然后，我们将提交代码并同时将其添加到暂存区。

您可能会惊讶地看到我们在 Git 和 Github 指南第 1 章中遇到的 Git 消息，Git 正在请求我们的信息。

这很合理，因为这是一台我在 Azure 中快速启动的电脑，还没必要配置所有东西。不过，这确实提供了一个机会，让我们回忆一下我们用来向 Git 提供信息的命令。

记住！您将添加自己的用户名和电子邮件，因为这是您以及您设置 GitHub 帐户的唯一标识。

我们通过输入以下命令来添加我们的用户名：

git config --global user.name John

接下来我们将向 git 提供我们的电子邮件地址，我们通过键入以下命令来添加它：

git config --global user.email john@gmail.com

我们继续提交，增加字体大小。接下来，我们修改了 h1 标签的颜色，然后提交并将其设置到暂存区。

我们记录了提交的历史记录，并在历史记录中看到了两个新的提交。

现在是时候将这些更改从本地存储库推送到远程存储库了。为此，我们运行以下命令：

git push origin master

我们可以看到更改已被推送到我们作为协作者的远程存储库，您应该注意到我们不必创建拉取请求，这些更改被推送到远程存储库，就像它是我们自己的一样。

要实现的另一个方面是更改如何在所有者存储库中发生，我们不需要请求许可或等待所有者审查代码。

这乍一看很棒，因为你无需费尽周折就能部署更改，但它也带来了一个问题：作为所有者，你不再拥有对仓库及其所经历的更改的完全控制权。这种协作流程是一种共担责任的模型。在共享环境/仓库中，每个成员都拥有平等的权利和权限。

保护你的分支

在现实世界中，平等共享的责任模式并不方便。如果你是一个项目的所有者，并且你的团队中有一些合作者，你通常需要一些机制来控制和管理团队的工作，以避免任何意外的结果。

Github 允许存储库的所有者通过在合并分支之前要求进行审查来保护分支。

让我们通过保护主分支来模拟刚才讨论的内容。

在大多数情况下，主分支是可部署的，并且没有人会出于测试目的触碰它，这意味着它必须受到保护。

为了保护分支，我们必须进入“设置”选项卡，在选项列表中选择“分支”。在这里，我们将看到一个标题，上面写着“分支保护规则”，在右侧，我们将看到一个按钮，上面写着“添加规则”。

点击“添加规则”，会出现一个表单，输入分支名称，然后在下方可以看到可以定义的规则。我们选择“合并前需要拉取请求”。

它将要求合作者在合并之前执行拉取请求，这将强制所有提交都必须对非受保护的分支进行，并通过拉取请求提交，然后才能与主分支合并。

我们还将所需的批准数量设置为 1，为了本次讨论的目的，这是有意义的，但在现实世界中，您可以想象许多合作者需要在合并之前批准拉取请求。

我们的主分支现在受到保护，为了确认这一点，我们可以在本地存储库上进行更改并将其推送到远程存储库。

注意！我正在使用 Azure 中的虚拟机来模拟不同的协作者。

我们对 index.html 文件进行了修改并提交。但是，当我们尝试将更改推送到 master 分支时，却收到一条错误消息，提示我们 master 分支受到保护。

这证明我们的主分支受到保护，并且我们可以从所有者的角度控制和管理变化的发生方式。

然而对于合作者来说，他们需要将更改推送到不受保护的分支并按照分支规则执行拉取请求。

基本上，我们需要创建一个新分支，将其推送到 GitHub，然后将其合并到主分支。

我们通过运行以下命令创建并切换到分支：

git switch -c test

这里的test指的是我们正在创建的新分支的名称。测试分支将包含我们刚刚进行的所有提交，因此我们只需运行以下命令即可将此分支推送到远程仓库：

git push origin test

如下所示，我们已将代码推送至远程仓库。为了将其与主分支合并，我们需要执行拉取请求。

请注意，当我们点击创建拉取请求时，我们收到了一些警告，第一个状态是“需要审核”，第二个状态是“合并被阻止”。此外，由于按钮已被禁用，我们无法合并拉取请求。

回到所有者帐户，我们刷新以查看最新更改，并看到我们有一个新的拉取请求。

在这里，我们将看到与合作者帐户上相同的警告，但是我们可以合并拉取请求，因为按钮未被禁用，因为我们是 repo 的所有者。

在合并分支之前，我们需要将审阅者设置为 1，因为这是我们创建的分支规则之一。

将我们自己添加到“审阅者”选项后，我们需要进入“文件更改”选项卡。在这里，我们可以找到协作者所做的所有更改。审阅更改后，如果所有者满意，他们可以通过点击右上角的“审阅更改”绿色按钮来批准更改。

在这种情况下，我们点击“批准”选项，并给合作者留下真诚的评论。接下来，我们点击绿色按钮“提交评论”。

我们可以看到拉取请求已被所有者批准，并且我们最终可以通过单击合并拉取请求按钮将更改合并到主分支。

如果我们检查提交历史记录，我们会找到协作者在合并提交之后所做的所有提交。我们可以看到相同的更改已反映在协作者的帐户中。

这就是我们保护分支和控制合作者在 GitHub 上工作的方式。

我希望你从本系列中获得至少一条知识，我个人学到了很多东西，并且比开始本系列之前更习惯使用 Git 和 GitHub。

虽然已经结束了，但我意识到 Git 和 GitHub 还有很多方面我还没接触过。我可能会去看看，分享一下我的经验。

现在我已经在 Git 和 GitHub 上签名了，这是一次有趣的旅程，感谢大家参与这次旅程。