如何组织你的 git 分支

Gitflow

Gitflow 增强版

BPMP（分支-推送-合并-修剪）

基于模块

基于版本

基于票证

基于表情符号

最后的话

我记得我曾在团队中实施过 git，大概是六年多前的事了。当时，如果你想学习如何有效地使用 git， Vincent Driessen的《成功的 git 分支模型》是必读之作。从那时起，我一直遵循“Git Flow”风格。但在过去的一年里，我受到了社区许多开发者的影响，开始根据我所从事的项目以不同的方式使用 git。

在讨论不同的分支样式之前，需要注意的是，虽然许多 git 客户端将斜杠（“/”）视为目录分隔符，但 git 规范中并没有文件夹或目录的概念。你会在许多 UI 客户端中看到这种实现，但我从未在控制台客户端或 Github 或 GitLab 等网站上看到过。

话虽如此，让我们探索一些组织分支的方法，这样您就不会迷失在代码的海洋中。

Gitflow

虽然 Gitflow 没有提到分支文件夹，但许多开发人员会使用“功能分支”、“修补程序分支”和“发布分支”，并相应地创建文件夹。
因此，一个 GitFlow 组织基本上会有以下三个文件夹：

• 特征]
• hotfix[es]/修复
• 版本

由于没有公开文件谈论此事，我看到一些工作副本使用复数文件夹，而其他工作副本使用单数文件夹。

Gitflow 增强版

我发现自己在 Gitflow 存储库中添加了两个文件夹：

• Docs：用于与 markdown 或发布文档相关的分支。
• 任务：针对既不是功能也不是修复的分支。例如，清理脚本或重构。

BPMP（分支-推送-合并-修剪）

我在很多项目中都见过这种情况。“分支-推送-合并-修剪”是一种反文件夹方法。我并不是说混乱是一种组织分支的方式。使用这种方法的人喜欢保持工作副本的整洁。他们只会创建分支、推送、创建拉取请求，然后在 PR 合并后立即删除分支（手动或通过 git fetch prune 命令）。

基于模块

我发现自己在一个大型项目中使用了所谓的“基于模块”的分支模型，结果在一大堆功能和修复中迷失了方向。于是我开始基于它的模块创建分支。

您可以将 Gitflow 与这种基于模块的方法混合使用，例如“backoffice/billing/fixes/billing-values”，但这可能太多了。

基于版本

我第一次看到Meir使用这种方法就爱上了它。这种方法非常适合像Puppeteer-sharp这样路线图清晰的项目。
在基于版本的仓库中，你会在“vX.X”文件夹中创建每个分支。这种方法的妙处在于它是基于时间的，因此更容易找到分支，而且使用这个简单的 git 命令删除旧版本也非常容易：

git branch | grep -e "vX.X/" | xargs git branch -D

同样，这可以与 Gitflow 文件夹混合，但是......

基于票证

如果工单编号（工单、问题或其他任何称呼）是团队语言的一部分，那么使用基于工单的系统可能是一个理想的选择。
您可以使用文件夹，例如“tickets/242”或“issues/242”，或者直接命名为“242”。

基于表情符号

如果这些系统都不适合您，您可以按照Nick 的想法并实现基于表情符号的系统 :)

最后的话

最后，在结束这篇文章之前，我想说两点。首先，如果你所在的团队经常互相检出分支（例如进行本地测试），我建议你与团队分享这种风格。
最后，要经常清理你的工作副本。这能帮助你快速找到你的分支，也能加快本地代码库的速度。

不要停止编码！

最初发布于harkoded.com