改善你的 Git 工作流程

无论您是独自一人还是与团队合作，拥有高效的 Git 工作流程都能极大地提升您的工作效率。

过去一个月，我一直在为一个团队提供咨询服务，他们非常重视我今天要分享的要点，并且我已经看到他们在大型项目中产生的积极影响。

命名约定

Git 命名约定是关键。它能让你在几秒钟内了解某人的工作背景，并在执行良好的情况下帮助你筛选团队的工作。

目前还没有一个完美的命名规范，但有些规范，比如Vincent Driessen 的规范，非常有意义，能够澄清 Git 分支命名可能带来的混乱。

简而言之，除了常用的master和dev分支之外，你的支持分支可以是以下类型：

• 功能分支（feature-*）：采用用户故事的形式，或稍后将合并的功能
• 发布分支（release-*）：支持新产品发布的准备工作，例如未来网站品牌重塑，最终将在准备就绪后合并
• 热修复分支（hotfix-*）：典型的 bug 修复分支。例如，你可以创建分支来修复生产环境中的 bug。

但命名约定也适用于提交信息。我强烈推荐 Chris Beam 的《如何编写 Git 提交信息》，以便您了解谨慎命名提交的重要性。但我认为以下准则可以作为一个很好的总结：

• 用空行分隔主题和正文
• 将主题行限制为 50 个字符
• 主题行大写
• 不要以句号结尾
• 在主题行中使用祈使语气
• 正文在 72 个字符处换行
• 使用正文来解释什么、为什么以及如何

一个好的经验法则是使用这样的句子：如果应用，此提交将……并以你的提交标题结尾。如果这听起来没有意义，你可能需要重新考虑。

例如：“如果应用，此提交将删除所有弃用的方法”听起来很棒，而“如果应用，此提交将修复错误 #123”听起来却不太好。

注意：如果您使用 Jira 之类的工具，可以将工单号添加到分支名称和提交信息中，以便于交叉检查。

另外，别忘了这些只是一些小技巧，最终您可以按照自己的方式操作。我们最终都会遇到一些“请继续工作”的提交信息。😄

Github 标签

Github 标签是另一种筛选拉取请求的好方法。以下是我过去发现的一些有用的标签及其含义（当它们的含义不太明显时）：

• 第一个问题很好：尤其适合开源项目，并且正在寻找新的贡献者。对于那些不敢提供帮助的人来说，这是一个很好的切入点。
• 特征
• 漏洞
• 技术：表示关联的拉取请求并非针对面向客户端的功能。例如，它可能与你的项目eslint或配置有关。storybook
• 关键：帮助您的团队了解哪些 PR 值得首先审核，尤其是在时间紧迫的情况下
• 把招工广告
• 进行中
• XS、S、M、L和XL：代表 PR 的大致尺寸。很难确定需要修改多少行才能达到这些尺寸，这完全取决于您。
• 需要审核
• 已审核

可以通过单击拉取请求页面中的以下链接来更改标签：

现在只需单击“新标签”，设置名称、可选描述和颜色即可。

保护 Git 分支

您可以通过强制执行特定分支合并前的必要状态来限制分支操作。当您设置了代码审查规则，并且不希望任何人误合并分支时，此功能非常有用。

作为项目管理员，转到Settings=> Branches=>Add rule并输入您希望保护的分支的名称。

您可以从许多规则中进行选择，其中包括：

• 合并前需要审核 X 个拉取请求
• 要求在合并之前通过状态检查，这在您拥有强大的 CI 流程时非常有用

创建 Git 钩子

我将引用这个官方文档：

Git 钩子是 Git 在提交、推送和接收等事件之前或之后执行的脚本。Git 钩子是一项内置功能，无需下载任何内容。

每个 Git 仓库都有一个 .git/hooks 文件夹，其中包含每个可绑定钩子的脚本。您可以根据需要随意更改或更新这些脚本，Git 会在相应事件发生时执行这些脚本。

我建议使用Husky等出色的工具来轻松创建它们。

自动执行测试并在失败时阻止推送将大大避免污染您的 git 历史记录。

荣誉提名

我想提一下我在个人项目中经常使用的工具，比如Foodpicker、Banner Generator或Gitignore It（如果你感兴趣，可以看看它们的 Git 历史记录）：🎨⚡️ Gitmoji🔥🐛！它是一种用表情符号来编码提交信息的方法，这样你就能一目了然地了解提交的上下文。有些人可能会因为它色彩鲜艳而直接忽略它，但我发现它在生成变更日志等方面非常有用。

gitmoji-cli和gitmoji-changelog等一些很棒的工具使我的 Git 日常体验更加顺畅，所以如果您有兴趣，请务必查看它们！

希望你读完这篇文章有所收获！一如既往，如果你有任何问题，欢迎在推特上@christo_kade

问我 😄 保重，别忘了：务必在本地进行 rebase ❤️