如何使用 Git 和 GitHub 进行协作编程？

2018年10月

最初发表于Medium

这是我之前发布的 Git 和 GitHub 基础教程的续篇。如果你是 Git 或 GitHub 新手，我建议你从这里开始阅读。

在您的组织主页上，您可以看到一个名为“新建”的按钮。点击它会打开一个窗口，您可以在其中填写一些详细信息并创建一个仓库，就像使用我们自己的帐户创建仓库一样。唯一的区别是，尽管该仓库是由您创建的，但它的所有者是组织，而不是您。这是什么意思？这意味着只有拥有您组织管理员权限的人才能对这些仓库进行任何操作，其他成员则无法操作。

别担心。目前，您是贵组织的唯一管理员。

您不能将代码推送到您刚刚在自己的组织上创建的存储库。

是的，你没看错。如果你真的想和你的团队、朋友或其他程序员同事合作，就不应该这么做。

正如我之前提到的，代码库归组织所有。这意味着每个参与项目的成员都必须了解项目进展。您不应该修改代码并直接推送。您需要提出修改建议并以提案的形式提交，以便其他成员审核代码，并在所有成员同意后才能推送。当组织像许多开源组织一样发展壮大时，只有授权管理员才能批准修改，以免破坏应用程序。

好吧，他们是怎么做到的呢？这就是分叉发挥作用的地方。

叉子

分支只不过是存储库的一个副本。

让我们分叉吧！

在您组织的项目主页中，您可以在右上角看到一个名为“ Fork ”的按钮，如下所示。

当你在组织中 fork 刚刚创建的仓库时，系统会询问你希望在哪个账户下创建此 fork。点击你的账户，你会看到你的用户名和头像。现在，你的账户下就有了组织仓库的副本。它被称为组织仓库的 fork。

你知道吗，你是这个复制的 fork 仓库的所有者。（尽管它继承了组织仓库的一些属性，比如安全配置等等。）

fork 和你自己的仓库有什么区别？

分叉始终链接到其他组织和其他组织的原始代码库，并将其作为父级。因此，如果您想向他们的代码库提出代码变更建议，您可以轻松地从分叉中提交，因为它显然知道它的父级。

您无法从您帐户中创建的其他代码库向任何其他代码库提出代码变更建议。这根本行不通。

您可以创建任意数量的分支，并通过向其推送提交来更改该项目中的任何内容。

但是，我们如何向组织的 repo 建议这些更改呢？继续阅读以找到答案。

拉取请求

拉取请求（又名 PR）是向父仓库甚至同一仓库中一个分支到另一个分支提出代码更改的方法。

无论何时，当你开发某个功能、修复某个错误，甚至是进行一些随机的代码更改时，通常你都会将代码提交到个人代码库并推送到云端。在组织的代码库中，你不能直接推送更改。你必须提出更改，然后组织的其他成员必须审核你提出的更改，并将其与组织的代码库合并。

因此，当代码库出现问题时，你不会是唯一一个承担责任的人。😝

但是，拉取请求不仅仅是一个变更提案。它是一个专门用于讨论拟议代码变更的论坛。如果变更存在任何问题，或者需要讨论某些代码变更，组织成员可以在拉取请求中发布反馈，甚至可以通过推送后续提交来调整代码。

让我们看看实际效果。

将你的 fork 仓库克隆到本地机器。创建一个新的分支，命名它feature/first-proposal，并在分支中进行一些代码更改，然后将提交推送到云端的 fork 仓库。

如果您不知道如何操作，请参阅我之前的文章。

现在在浏览器中打开你的 fork 仓库。你会看到一个下拉菜单，用于更改项目，如下所示。

feature/first-proposal现在通过下拉菜单选择转到您的新分支。

让我们通过点击分支选择下拉菜单旁边的“新建拉取请求”来发起一个拉取请求。现在，它只会预览您即将发起的拉取请求。您可以更改任何详细信息，修改拉取请求名称，并更改您提议代码更改的父分支。确定所有详细信息后，点击“创建拉取请求”以确认提案。

您已成功向组织代码库提交拉取请求。现在，我们需要做的就是分享此 PR 的链接，让组织中的任何其他成员可以审阅此拉取请求。您只需从浏览器地址栏复制链接即可。

代码审查流程

当你提出 PR 时，组织的其他成员会审查你的代码，只是为了确保你没有通过添加一些额外的代码或删除一些代码来破坏项目的任何现有功能。😝

反之亦然，您必须检查队友的代码，以便了解项目的进展情况。

那么我们该怎么做呢？

单击如下所示的“文件已更改”选项卡，将打开一个页面，以某些颜色代码显示您或您的队友更改的所有文件中的所有代码更改。

在上图中，绿色代码表示已添加到项目中，红色代码表示已从项目中移除。此外，每行代码前都带有+或-符号，其含义与颜色代码相同，一目了然。

审阅者必须仔细检查所有代码更改，看看代码中是否存在任何明显的错误。如果发现任何错误、需要改进的地方或遗漏的地方，审阅者可以对该请求发表评论。你无需前往任何地方发表评论，GitHub 的一个很棒的功能是，你可以在任何一行发表评论，之后查看此 PR 的人都会看到该行。

将鼠标悬停在代码上时，您会看到+一行代码开头前出现一个带有（加号）图标的蓝色按钮，点击它会在同一行中打开一个评论框。您可以输入任何内容，标记组织中的任何人，以及像其他评论框一样执行更多操作。甚至还支持表情符号。😉

然后，请求者将通过电子邮件和 GitHub 通知收到有关其 PR 中评论的通知。审阅者也可以在任何聊天中通知请求者，以立即引起他们的关注。PR 中的对话可以继续，也可以进行相关更改并将其与更多提交一起推送到同一分支。

在请求者处理完审阅者留下的所有评论后，“文件已更改”页面将会更新，审阅者必须再次检查更改，以确保在下一次提交中不会发生更糟糕的事情。😝

请阅读这篇文章，这是一篇有趣的文章，介绍了如何以礼貌友好的方式完成拉取请求和代码审查过程。

一旦一切看起来都很好，审阅者必须通过单击“审阅更改”按钮来批准拉取请求，并选中“批准”单选按钮提交，如下所示。

并通过单击“合并拉取请求”按钮并确认，将拉取请求与组织存储库的主分支合并，如下所示。

除非已配置，否则拉取请求无需获得批准即可与组织代码库合并。因此，您可以自行审核代码更改，并将其与主分支合并，无需获得批准。但理想情况下，不建议这样做。

部署

在组织的项目中，我们将通过任何服务提供商（例如 Amazon Web Services、Azure Cloud、Google Cloud Platform 等）通过 FTP 或某些容器化工具（Docker 或 Kubernetes）将代码部署到云端的某个地方。

每当我们做出更改时，我们可能希望将代码部署到任何云服务中创建的任何服务器实例。

如果你以前做过，或者听说过，完全没问题。我们现在不打算讲这个，因为这个话题很宽泛，需要专门学习。

如果您的组织中 DevOps 团队或其他人员从事这些工作，那么现在是您学习并与他们合作完成此过程的最佳时机，因为这正成为开发人员必备的技能。

由于各服务提供商的官方网站和其他在线资源都提供了大量资源，因此我们不打算介绍部署步骤。我们只会讨论如何使用 git 存储不同版本的代码库，以及如何区分最新发布的版本以简化部署流程。

让我们将此标签推送到您在云端的 fork 仓库。
git push origin v1.0
上述命令会将标签推送到您的 fork 仓库，这意味着您已在云端备份了项目文件。您可以随时获取和恢复这些文件。当部署的服务器出现故障时，您可以使用这些标签回滚到项目的先前版本。通常，标签会推送到组织的仓库，而不是任何人的 fork 仓库，以确保标签在整个组织范围内可用。

那么我们如何恢复推送到云端的标签呢？

该命令git fetch origin将获取所有分支，并将所有标签下载到本地计算机。

您可以通过执行来查看所有标签git tag。它将列出本地机器中所有标签的名称。

假设您进行了大量提交并转移到其他分支，而您的产品所有者/经理要求您回滚到云服务器中的开发环境的v1.0版本。

您可以使用上面列出的命令从云端获取所有标签。您可以使用git checkout origin/v1.0类似 checkout 到分支的操作来恢复特定标签。它将从您备份的标签 v1.0 恢复代码。现在，您可以继续从本地计算机将代码部署到服务器。