改善您的Git工作流程

无论您是自己还是团队，拥有高效的Git工作流程都可以大大提高您的工作效率。

在过去的一个月里，我一直在咨询一个真正重视我今天与您分享的观点的团队，我已经能够看到他们对大型项目产生的积极影响。

命名约定

Git命名约定是关键。它们允许您在几秒钟内了解某人的工作环境，并可以帮助您在执行良好时过滤团队的工作。

没有一个完美的命名约定，但其中一些，如Vincent Driessen的说法很有意义，并将澄清可以命名Git分支的混乱。

总之，除了平常之外 master 和 dev 分支机构，您的支持分支机构可以是以下类型：

• 特色分支（feature-*）：采用用户故事的形式，或稍后将合并的功能
• 发布分支（release-*）：支持新产品发布的准备，比如您的网站未来的品牌重塑，并在准备好后最终合并
• 修补程序分支（hotfix-*）：您典型的错误修复。例如，您可以分支以修复生产中的错误

但命名约定也适用于提交消息。我真的推荐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将在这些事件发生时执行它们。

我建议使用像赫斯基这样的很棒的工具来轻松创建它们。

如果它们失败，自动执行测试并阻止推送将大大有助于避免污染您的git历史记录。

荣誉奖

我想提一些我在个人项目中使用的东西，例如Foodpicker，Banner Generator或Gitignore It（如果你很好奇，看看他们的Git历史）：??️Gitmoji??这是一种使用表情符号编写提交消息的方法，这样您就可以一目了然地了解提交的上下文。由于其丰富多彩的性质，有些人可能会马上解雇它，但我发现生成更改日志非常有用。

一些很棒的工具，如gitmoji-cli和gitmoji-changelog，让我的Git体验每天都更顺畅，所以如果你有兴趣，请务必查看它们

我希望你在阅读这篇文章时学到了很多东西和往常一样，如果您有任何疑问，我会很乐意向您发送@christo_kade的推文?

小心，不要忘记：总是在当地重新❤️