在您的项目中采用 Git 工作流程可以简化项目管理并提高一致性。有几个 Git 工作流程旨在满足 Git 用户的需求：一些很简单，而另一些则更复杂，旨在用于大型项目。在这篇文章中，我将与您分享我在机器学习和数据科学项目中采用的自己的 git 工作流程。我的工作流程介于简单和复杂之间——既不太简单也不太复杂。不拖延，让我们深入探讨！
不是 Medium 会员？不用担心！通过这个*朋友链接*继续阅读。
简介
Git 工作流程被定义为一系列约定和实践，旨在标准化项目版本控制的管理，从而提高一致性和促进协作。在先前的教程中，我详细介绍了我认为最基本且必须学习的 3 个工作流程：即功能分支工作流程、分叉工作流程和Gitflow 工作流程。
在功能分支****工作流程中，为每个功能开发、错误修复和其他面向项目的任务创建一个专门的分支。在分叉工作流程中，官方服务器端仓库被克隆到服务器端个人仓库；当需要更新官方仓库时，将更改推送到个人仓库并执行拉取请求。正如在Gitflow 工作流程中，为分支的组织和管理建立了一套约定：它定义了特定的分支名称及其角色。第一个工作流程很简单，第二个工作流程通常在直接更改官方仓库权限不足时使用，例如在开源项目中；第三个工作流程是为持续发展的实时项目设计的。如果您对这些工作流程感兴趣，我邀请您查阅我的教程：精通 Git：高效版本控制的 3 个基本工作流程。
我的 Git 工作流程实际上受到了 Gitflow 工作流程和机器学习项目项目结构的启发。我在如何创建分支、它们的角色以及如何管理它们上建立了一套约定和规则。我称我的工作流程为：机器学习工作流程！
机器学习工作流程
由于这个 Git 工作流程是受机器学习项目结构的启发，让我们简要回顾一下项目结构的基本模板。一个机器学习项目主要包括以下文件夹和文件：
mlops_template/
├── LICENSE
├── README.md
├── Makefile
├── configs
│ └── model1.yaml
│
├── data/ # Data set
│
├── docs/ # Project documentation.
│
├── models/ # Trained and serialized models.
│
├── notebooks/
│
├── references/ # Data dictionaries, manuals, ...
│
├── reports/ # Generated analysis as HTML, PDF, etc.
│ └── figures # Generated graphics and figures ...
│
├── requirements.txt
└── src # Source code for use in this project.
├── __init__.py
│
├── data/ # Data engineering scripts.
│
├── models # ML model engineering
│ └── model1
│ ├── dataloader.py
│ ├── hyperparameters_tuning.py
│ ├── model.py
│ ├── predict.py
│ ├── preprocessing.py
│ └── train.py
│
└── visualization/
如果您对机器学习项目的结构细节感兴趣，请参阅我的教程：以 MLOps 为视角构建您的机器学习项目结构。在众多文件中，我特别关注那些未被 Git 忽略的文件。这些文件可以分为 5 个不同的组：
-
项目配置文件，例如：
Licence、README.md、makefile和requirements。 -
包含笔记本文件、文档文件、报告文件和参考文件的文档文件。
-
数据处理的脚本。
-
模型创建、训练和验证的脚本。
-
可视化的脚本。
这种分组启发了我设置的不同分支，以定义我的 Git 工作流程。
机器学习工作流程也受到 Gitflow 工作流程的启发，它是一种功能分支工作流程，具有一些分支命名约定和规则。我采用新工作流程的原因是，似乎只有一个名为“feature”的分支类型更适合软件或 Web 开发。然而，在机器学习项目中，我始终觉得需要在项目结构和 Git 分支中分离任务。因此，我改进的工作流程包括一个单一的主要分支（主分支或 master 分支）和七种支持类型的分支：
-
主分支代表项目的工作代码，而不是像 Gitflow 工作流程那样有两个分支（生产就绪分支和开发代码分支）。主分支命名为
main或master。 -
配置分支代表不同的项目配置文件，包括：许可文件、make 文件、需求文件等。它们的名称前缀为config，如下所示：
config/<config_name>。 -
文档分支表示不同的项目文档，包括：笔记本文件、文档文件、报告文件和参考文件。它们的名称前缀为document或doc，如下所示：
document/<doc_name>或doc/<doc_name>。 -
数据分支是为与数据处理相关的新功能开发而创建的，包括：数据摄入、清洗等。它们的名称前缀为document或doc，如下所示：
document/<feature_name>或doc/<feature_name>。 -
模型分支是为与机器学习模型管理相关的新功能开发而创建的，包括：创建、训练和验证。它们的名称前缀为model，如下所示：
model/<feat_name>。 -
可视化分支是为了与不同类型的可视化相关的新功能开发而创建的。它们的名称前缀为 visualization 或 vis，如下所示：
visualization/<feature_name>或vis/<feature_name>。 -
热修复分支是为了修复项目代码中的问题而创建的，其名称前缀为 hotfix，例如：
hotfix/<hotfix_name>。 -
测试分支是为了功能测试而创建的，但它取决于项目的复杂性，是可选的。其名称前缀为 test，例如：
test/<test_name>。
描述的分支管理如下：
-
如果在 main 分支中检测到问题，就会从 master 分支创建一个 hotfix 分支，一旦完成就会合并回 main 分支。
-
测试分支是从 main 分支创建的，一旦完成就会合并回它。
-
功能分支（文档、配置、数据、模型和可视化）是从 main 分支创建的，一旦完成就会合并回它。
总结来说，所有分支都是从 main 分支创建的，并在完成后合并回它。您可以添加其他分支以实现额外目的，或者为每种文档类型设置一个分支。然而，我建议保持具有显著角色的分支数量简洁。这种方法的优点在于其灵活性：当需要时，您可以轻松切换到其他更详细的流程，例如带有 dev 和 release 分支的 Gitflow 工作流程。
结论
这篇文章到此结束！在这篇文章中，我与你分享了我是如何使用我个人的版本控制工作流程来管理我的 AI 项目的。你对这种方法有什么看法？你有没有自己的有效工作流程？请随时在评论中与我们讨论！我们期待着这次讨论。
我通过我的文章的目的是提供清晰、组织良好且易于遵循的教程，为读者提供我对涵盖的多样主题的坚实基础介绍，并促进良好的编码和推理技能。我一直在进行自我提升的旅程，通过这些文章与你分享我的发现。我自己也经常在需要时参考自己的文章作为宝贵的资源。
感谢阅读这篇文章。如果你喜欢我的教程，请通过关注我和订阅我的邮件列表来支持我。这样，你将收到关于我新文章的通知。如果你有任何问题或建议，请随时留言。
图片来源
本文中的所有图像和图表，如果其来源在图注中没有提及，均为作者所有。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
