团队使用 GitHub

初次使用 GitHub 的学习曲线非常陡峭。与团队一起使用 GitHub 则完全不同。以下是我在团队项目中积累的一些最佳实践。

在我参与过的各种开源项目（OSS）中，有一件事总是比我预期的要耗费更多时间。那就是为代码仓库（或者像一些酷孩子说的那样，叫 repo）的开发设置一个 Git(Hub) 标准。以下是一些对我帮助很大的最佳实践。

保护你的分支机构

避免将来出现麻烦的首要方法是保护master分支并develop立即创建一个。它可以禁用强制推送并防止分支被删除。这是一个很好的方法，可以保护你的项目，并确保你无需🚑在持续集成等情况下进行任何热修复。

一致的分支命名

由于master分支受保护，贡献者无法直接推送到master。他们必须使用分支并 make pull requests。为分支制定命名约定非常有帮助。其中之一就是使用前缀：

• fix/...
• feature/...
• enhancement/...

通过快速概览，您可以看到每个分支的用途，并且它们具有一致的命名。

拉取请求

确保 PR 未经必要的审核就无法合并。如果您保护了某个分支，还可以启用Require pull request reviews before merging。每个提交的 PR 都必须由另一位贡献者审核。

因此，合并操作默认被阻止。贡献者必须手动导航到该 PR 并点击review changes。然后您可以：

• 发表评论以获取一般反馈。（无需明确批准）
• 批准更改，然后可以合并 PR
• 请求更改，合并之前必须修复的事情。

这是在代码合并之前进行快速质量检查的好方法。

• 它使代码的整体质量保持稳定。
• 多看几眼👀就更好了。别人或许能发现你可能忽略的错误。
• 就我个人而言，我认为通过查看别人的代码是一种很好的学习方法。

提交消息

天哪，提交消息。这总是个令人头疼的话题。每个人都有自己/偏好的提交方式。Chris Beam在 2014 年写过一篇很棒的文章，讲的是一些通用规则，但大多数人都能接受。

您绝对应该阅读完整的帖子。

理想情况下，您的提交标题应如下所示：

Add styling for navigation bar

通常这些规则在中都有概述，contributing.md并且给出了示例。

规划你的提交

提交大量代码确实令人感到内疚。但是，规划好你的提交也是一个控制自己的好策略。在直接构建某个功能之前，尝试将其分解成几个小步骤。这样，每个步骤就代表一次提交。这里有一篇关于此的简短文章，发布在 dev.to 上。

制定一致的 GitHub 标准和流程可能需要一些时间，但从长远来看是值得的。它使代码库更易于维护，也让我免于陷入恐慌。

感谢阅读！你可以在@dandevri关注我，如果你有什么想说的，欢迎随时联系我！