“保持热爱，奔赴星海”
Git Flow是一种标准Git分支模型，由Vincent Driessen于2010年提出，他开发的插件git-flow可以自动化完成分支的创建、合并等工作，大大减轻了分支操作的工作量。在十几年前Git刚刚出现的时候是有意义的，当时SVN比较普及，人们不太懂如何使用Git。
但在十几年后的今天，由于Git Flow的结构过于繁琐和复杂，它完全放弃了rebase，分支结构错综复杂，即使有插件git-flow，但使用和维护起来的工作量仍然不小，不利于现如今的持续交付流程。
我们需要一种新的Git分支模型来适应现代化的开发需求，本文推荐由Fork的开发者提出的Lean Branching：⭐️ Lean Branching - a git branching model to keep clean history · Issue #1432 · fork-dev/TrackerWin
Git Flow是一种标准Git分支模型，阅读本文前，建议先阅读文章“标准Git分支模型介绍（配合Fork实操） | 青江的个人站”以了解Git Flow的基本流程。
可以看到，Git Flow流程中有着大量的新建、提交、合并分支的操作，导致整个过程非常繁琐，加大了开发的工作量。
因此，Git Flow的创造者Vincent Driessen开发了git-flow插件（nvie/gitflow: Git extensions to provide high-level repository operations for Vincent Driessen’s branching model.），可以通过一行命令来自动化地创建或完成支持分支，从而简化操作。
此外，Fork支持git-flow，可以在图形界面中完成整个流程。
本文将配合Fork对git-flow插件的使用做基础的介绍。
本文参考文章：A successful Git branching model » nvie.com，作者是Vincent Driessen
本文在原文的基础上做了本地化以及一部分现代化改动，例如将文章中的主分支名
master改为现在更为常用的main等，同时配合Fork做一些实操介绍。
阅读本文前，建议先阅读文章“【保姆级教程】Git客户端Fork的基础使用 | 青江的个人站”以了解Git与Fork的基础用法。
使用标准Git分支模型的核心作用是为代码的集成、测试和发布建立清晰可控的工作流程，避免非标准分支导致的开发混乱、出现问题时难以排查或回溯的情况。
通过定义如长期稳定的main主干分支、临时性的功能开发分支（feature）、预发布测试分支（release）以及线上问题紧急修复分支（hotfix）等角色，该模型将不同开发阶段和目的的工作有效隔离，避免相互干扰；这使得团队成员能够安全地并行推进多个任务，同时始终保证主干分支的代码处于可随时发布的稳定状态，从而显著降低集成冲突风险、提升软件交付质量与效率，并为版本追踪、问题排查及协作沟通提供了结构化的历史记录基础，最终实现开发过程的有序性和可靠性。
下面是一个完整的标准Git分支模型示意图：
Fork是一个Git客户端，可以在可视化图形化界面中实现Git仓库的拉取、提交、推送以及分支的新建、合并等操作。
Fork还可以直接与Gitea账户进行连接，实现直接管理Gitea账户中的仓库。
Fork界面：
如果一个程序中需要同时定义一系列数据，单独分开定义显然是不合适的，这时候就需要用到数组。
编程语言设计需要考虑多个数据和变量如何处理，从下面三个方面来入手：
其中最简单的一种方式就是数组。
MinIO是一种高性能、S3兼容的对象存储。就是一个网络目录，可以上传文件、下载文件，可以通过网址访问文件。
一般想要在PicList中上传图片到MinIO图床时需要安装MinIO图床的插件，但在没有安装Node.js环境的情况下安装插件会提示安装失败。
由于MinIO兼容S3对象存储，测试发现可以使用PicList内置的“AWS S3”图床来实现图片上传。
循环就像在操场上绕圈跑步，需要有以下几个逻辑：
循环的作用：
今天想要使用Markdown的Mermaid流程图功能，Typora中可以正常渲染，但是使用Hexo生成静态网页，流程图果然无法正常渲染。
可以通过安装Mermaid渲染插件并做一些相应的配置来实现Mermaid的正常渲染。
有的Hexo主题自带支持Mermaid渲染，这里只针对本身无Mermaid渲染功能的主题，如本博客使用的Yilia。
编程语言最初的设计，是为了：
要搞清楚程序背后的逻辑。
运算符的分类：
+、-、*、/、%）==、!=、>、<、>=、<=）&&、||、!）=）