Github 的不成文规则，作者：devdiscuss

分支

开源

职业发展

其他/一般

不久前，@ThePraticalDev 在 #devdiscuss 上发帖，引发了一场关于用户如何充分利用 Github 的建议的热烈讨论。这些建议涵盖个人使用、团队使用、开源、职业发展等等。我特意整理了一些最佳建议，并撰写了这篇文章。

分支

我感兴趣的第一个话题是分支。当时，我刚开始着手一个有 30 多个分支的项目，大部分都被放弃了。我的第一个问题是：如何正确使用分支？什么方法最有效？它们真的有效吗？

大家似乎都同意分支才是最佳选择。以下是原文，并附上以下建议的署名。由于许多相同的建议被多次推荐，因此值得分享。

• 为每个新功能创建一个分支，并在功能合并到主分支后删除该分支。
• 经常重新设置 master 以减轻合并的痛苦。
• 创建一个用于概念验证工作的分支。
• 当您必须将焦点转移到另一个项目时，为未完成的功能创建一个分支。
• Git Flow 被提到过几次。我对它了解不多，所以就留下这个教程。
• 错误修复和重构也应该在分支中完成。
• 为开发和生产分支设置分支也是一种很好的做法。除了开发分支的部署之外，生产分支基本不会受到影响。
• 分支可以是任意大小。
• 拉取请求允许您即使在分支被删除后仍跟踪代码更改。
• 标签发布。
• 使用代码审查来确保质量。
• 分支应该具有与主干/主干相同的测试覆盖率。

值得注意的是，虽然有些人不使用分支功能，但大多数反馈表明分支功能是最佳选择。虽然没有详细说明，但仅根据我的经验，如果项目参与人员不多，而且他们各自负责不同的部分，工作内容重叠很少，那么不用分支几乎不会带来任何麻烦。然而，随着团队规模和代码库规模的扩大，使用分支的益处也随之增加。

开源

• 了解编写代码的人员，了解他们的名字，加入 slack，了解他们并在需要时寻求帮助。
• 如果你不确定从哪里开始，即使标记出 readme/documentation 中令人困惑或看似不完整的部分，也会很有帮助。与世界各地的人合作，接触不同的编码风格。
• 拉取一切请求。

职业发展

• 发布你正在学习的内容
• 如果你要演讲，请将代码、幻灯片、笔记全部放在 Github 上
• 公开代码可以帮助你理解 Git 工作流程，即使只有你一个人。它还能帮助你有意识地努力创建干净的代码。
• 构建一些任意大小的东西，使用干净的代码、测试、注释，尽一切努力来展示你的能力。

其他/一般

• 不要盲目接受代码审查，请留下您所验证的内容的评论 - 即使它只是您喜欢或不喜欢的代码。
• 永远不要发布私钥/API 密钥/证书。
• 集成 linters 和代码检查器
• 集成用于构建软件的持续集成 (CI)。
• 使用描述性的提交消息和拉取请求消息。
• 使用与其对应的票号标记您的提交消息。

您还有什么要补充的吗？

最初发布于KaydaCode