Git + GitHub 团队最佳实践（个人观点）

免责声明：本文改编自 Bits of Good 组织内部编写的指南，旨在帮助新手在加入项目团队时快速上手。如果您感兴趣，可以点击此处了解更多关于该组织的信息。是的，我们将在接下来的几个月里重新设计网站 :)

市面上有很多 文章都对如何最佳使用 Git 提出了新见解。鉴于 Git 的多功能性和自由度，很容易找到适合每个人的新系统。因此，实际上并没有一个所有人都必须遵循的万能黄金标准。所以， 不要把这篇文章的内容当成法律！这只是一篇观点文章，其中包含了我们 Bits of Good 组织发现的一些有效建议。

请注意，Bits of Good 是一家大学级别的组织，因此我的观点基于在小型团队工作的经验，而非在大型公司工作的经验。鉴于我的经验有限，诸如积压、工单和用户反馈等问题不在此处讨论。

内容

1. 创建和组织问题
2. 使用 Gitflow 的分支流
3. 分支最佳实践
4. 践行最佳实践
5. 拉取请求最佳实践

创建和组织问题

在开始修改代码库之前，我们先来聊聊如何组织需要完成的工作。GitHub 上有一个很棒的功能，可以创建“问题”来将任务分解成可分配的块。这在团队协作中很有帮助，可以确定截止日期和优先级，确保每个人都按计划完成任务。

一篇好文章应该说什么

让我们从一个糟糕问题的例子开始：

不仅最终结果不清晰，而且根本无法提供足够的方向来避免新手的头脑爆炸。帮大家一个忙，把问题分解一下！

GitHub 本身很贴心，每次你创建新的 issue 时都会包含示例标题。这些标题对于入门来说非常棒，但对于你创建的问题来说可能有点太多了。至少，请尝试包含以下内容：

1. 如果是功能：添加到项目中的功能的描述
2. 如果是 bug：请描述 bug 是什么以及如何复制它
3. 行动项目细目。这应该是一个列表（最好带有复选框），其中包含为完成功能/解决错误而需要完成的简短任务。
4. 关于功能/错误或未来可能需要的改进的一般说明
5. 如果团队仍需决定某些细节，请讨论以下要点

行动事项应该是问题的重点。您可以根据需要选择细节或技术性描述，只要它能帮助读者更轻松地理解问题即可。建议添加指向潜在解决方案的超链接，并提供一些辅助图片（例如模型）作为指导。

可选：像教程一样将行动项目分解，引导读者了解一种可能解决问题的编码方法。这对于新团队成员非常有用，这样他们就不会在不熟悉的代码库中感到迷茫。

下面是一个示例，说明如何解决之前令人困惑的单行问题：

利用里程碑

如果您的团队恰好使用敏捷开发或其他形式的快速发布周期，那么您应该避免在没有任何完成时间表参考的情况下随意处理问题。GitHub 允许您使用“里程碑”来集中查看每个开发周期/冲刺的工作内容。这只不过是代码库中特定时间点问题的子集。

要查看这些内容，请在“问题”选项卡中查找“里程碑”按钮。在这里，您可以创建一个新的里程碑，并为其指定标题、描述和截止日期。创建新问题时，您可以使用侧边栏将问题添加到指定的里程碑上。一般来说，请确保每个里程碑中的问题不要太多。可能需要一些时间来估算某些任务的完成时间，因此一开始要保持乐观，并根据工作量调整进度。

回顾一下我们团队过去按照敏捷开发计划完成的里程碑。我们发现表情符号有助于聚焦里程碑目标😛

使用 Gitflow 的分支流

进入一个新项目后，我们很容易立刻想到“管他什么手续，我要开始写代码了！”然而，兴奋之余很容易忘记一个重要的细节：你应该始终先从开发分支分支出来！

这种方法通常不适用于 Git 新手项目，他们通常只从 master 分支分支，并在代码获得批准后立即合并。这种方法对于大多数情况下只有开发人员才能看到的小型项目非常有效。然而，当用户参与其中，并可能随时访问实时项目时，将每个更改推送到 master 这样的“生产”分支可能并非明智之举。例如，假设你所在的团队正在构建一个通知仪表板，其中两名开发人员分工负责 UI，第三名开发人员负责 API 端点。与其推送到 master 分支或使用一些尴尬的中间分支，不如推送到开发分支，优雅地合并所有人的更改，这样岂不是更好？

这个过程被称为Gitflow，它使用一个develop分支来构建功能，并使用另一个master分支来编写面向用户的代码。其他流程包括进一步的分支阶段，例如一个staging分支，用于在代码合并到master分支之前对其进行测试和验证。

在 Git 中设置此流程非常简单。只需保留默认master分支，将其视为生产分支，然后develop从该分支签出一个新分支master即可。同时，请确保所有对项目的拉取请求都指向此分支，而不是 master 分支！大多数情况下，唯一提交到 master 的 PR 应该来自开发分支本身。

分支最佳实践

如果你之前参加过研讨会或基础 Git 教程，你可能创建过类似Ben-Holmes、bug-fix或 这样的分支名称homepage-57。请不要这样做！

一般来说，尽量像为自己制定一项总体待办事项一样为分支命名。因此，分支名称应该足够清晰，让你清楚地知道自己在做什么，但字数最好控制在 5-7 个字以内，以免队友无法输入。此外，分支的范围应该更集中而不是更宽泛，这样你所有的提交都集中在一个共同的问题上。这样做还有一个额外的好处，那就是避免在编码过程中出现一些小的“支线任务”。如果你在启动页面上看到一个与你正在处理的工作无关的小拼写错误，请不要在当前分支中进行修复！

格式化

当然，您可以使用最适合团队的方法，但可靠的做法是：

1. 分支名称可以用你的名字或 Git（hub、lab 等）用户名开头。这样方便以后返回查找你的分支。
2. 包含你的分支解决的问题编号。如果你构建的某个项目没有附加问题（不要经常这样做！），请在你的分支尝试解决的问题上添加一个简短的标签。例如feature，，，等等bug。poc
3. 添加一个 4-5 个字的标题，描述你的分支功能。你可以使用短划线、下划线或驼峰命名法来分隔单词。
4. 使用一致的字符来分隔所有这些👆，例如点或破折号。你也可以使用斜线，但这可能会带来一些意想不到的后果！

让我们看一个例子

假设您正在处理一个名为“ #154：在‘我的账户’页面添加头像编辑功能”的问题。顾名思义，您将在用户的账户管理页面中添加一个选项，用于编辑他们的头像，例如，当用户点击图片时。以下是该问题的一个合适的分支名称：

git checkout -b pr0H@ck3r.154.my_account_edit_profile_pic

是的，对于一个简单的分支名称来说，这种结构确实比较死板。然而，当同时有数十甚至数百个分支开放时，它确实能提高快速浏览的效率！

践行最佳实践

一天的工作结束了。你喝完了第三杯咖啡，终于修复了一个耗时数小时才找到的 Internet Explorer 错误。现在，你准备推送修改，然后关掉电脑。那么，如何才能最好地与团队沟通你经历的所有痛苦和煎熬呢？

git commit -m "fixes"

😓☕️ 嗯……绝对不是这样。提交信息不是一堆没人会看的、随手可得的文字。这是开发者解释代码意图的机会，所以当其他人梳理你的修改日志时，他们能够逐步查看提交，并追踪哪些修改值得添加。这对于偶尔的回滚来说非常宝贵，因为超过某个提交的修改应该被废弃。

撰写好的提交信息

那么，如何才能充分利用提交信息呢？首先，最好用一些动词来描述提交到项目后会完成什么。这通常是一个现在时态的短语，例如“添加”、“修复”或“包含”。

接下来，用一个简短的短语描述提交的目的，通常不超过 50 个字符。如果您使用 VS Code，内置的提交菜单（侧边栏下方第三个按钮）会帮您完成这项检查。这个限制应该用来检查提交内容的重点。例如，如果您提交的是修复 Internet Explorer 中不合适的个人资料图片的错误，那么一条明确的消息可能是：

git commit -m "fix profile picture position on homepage IE"

间隔你的提交

是的，这是一个相当容易设计的例子。提交可以轻松地跨越更多文件和更多功能。请始终尽量控制字符数限制，但如果内容太多，可能需要将提交拆分成更小的块。

这乍一听可能有点吓人，但 Git 提供了一个便捷的工具，方便你在暂存所有内容以进行提交时使用：git add -p。它不是一次性暂存所有更改，而是允许你逐个文件地浏览代码库中的每一项更改，并为你提供了每一步暂存的选项。以下是暂存一些 ESLint 配置文件的示例输出：

在这里，我们看到一个脚本添加到了文件中package.json，以及一些用于响应暂存的方法。如果您不确定所有这些随机字母的含义，只需输入“？”即可。

对于较大的提交来说，这可能是一个繁琐的过程，但对于刚开始使用 Git 的人来说非常有帮助。像疯子一样提交也是最安全的，这样你的更改更容易总结，你也不必经常进行这种羞愧的“走一遍”。

扩展阅读：本节的大部分内容来自经验和各种 Stack Overflow 来源，但这是一篇关于高质量提交消息的精彩长篇阅读文章。

拉取请求最佳实践

到目前为止，我们讨论的 Git 操作都是相当标准的：阅读问题，创建分支，提交代码，然后推送。现在，把所有内容推送到开发分支就完事了，这很容易……但是等等！如果你在团队中工作，最好在合并更改之前，请其他人审核一下。

拉取请求的第一个最佳实践是......直接执行🤷每当您创建的分支解决了问题并且您的更改被推送时，就发起 PR。

诚然，在终端上执行此操作不太好，所以直接从 GitHub 上执行可能是最简单的。请注意，PR 的目的是允许其他人在合并到另一个分支（通常是开发分支）之前查看你的更改，因此请确保你已经将远程分支 rebasemaster到develop你的分支上，以便更轻松地查看更改。

注意：如果您不熟悉 rebasing，它本质上就是合并，但会调整提交历史。使用 rebasing 后，远程分支中的所有提交都会被放置在您自己的提交之前，这看起来就像您的分支是基于新的远程分支构建的。这篇文章有一个很棒的视觉辅助工具来演示它的工作原理。

拉取请求发出后，请添加人员进行审核，以便他们收到通知。通常最好联系那些未曾与您一起参与变更的人，以便他们能够以全新的视角审核您的方法。但是，如果您是结对编程的爱好者，在与您的合作伙伴进行充分沟通后，可以绕过审核流程。

以下是我认为好的拉取请求的示例。首先，请注意，团队负责人被请求进行审核（在“审核人”部分中打勾表示）。另请注意，评论框提供了分支中所做的更改的详细分析。您可以自行选择结构，但最好至少包含以下内容：

1. 包含问题编号，以便读者可以参考正在解决的问题
2. 写出每个新增功能或为解决错误而做出的更改的项目符号/编号细分

下方是请求合并的分支中每次提交的日志。由此可见，高质量的提交信息有多么重要！

谢谢阅读！😊

我是一名前端 Web 开发者，一直在摸索着做着新东西。我会定期在这里更新，如果你喜欢的话，可以关注我一下！