第三部分 代码管理flow

当我们完成一个模块的开发，便来到了代码提交的环节。

本文主要讨论一些常见的flow，并不会给出最佳实践。

一提到"gitflow"，许多人会立刻联想到项目提交和发布的标准流程。然而，实际情况远比这复杂。许多团队虽然声称遵循"gitflow"，但在实际操作中却有着各自的"非规范"实践。

在我所接触的项目中，无论实际管理方式如何，团队成员在提交代码时常常会相互确认，询问应该从哪个分支拉取代码，以及如何合并。这种现象揭示了一个事实：尽管"gitflow"被广泛提及，但每个公司的流程可能大相径庭。

"gitflow"与业务流程

记得在一家公司工作时，他们的流程虽然号称是"gitflow"，但规范文档却冗长且复杂。总结起来，他们的流程需要考虑：

• 多个终端（iOS、安卓）的开发。

• 每个终端不同版本的适配。

• 每个业务模块的独立分支。

• 同一分支内的多个版本管理。

在这种情况下，他们并没有提供一个清晰的"flow 图"，导致只有主管或资深员工才能准确完成发版工作。

我们经常忽视了"flow"的重要性，而过分关注工具本身。每个项目都有其特定的业务需求，这使得标准"gitflow"模型并不总是适用。实际上，"flow"应当根据业务需求来定制，而不是被业务人员或管理层所左右。

业务需求是决定"flow"的关键因素。

常见的"flow"模式

1. 狭义的gitflow： 通常包括主分支、开发分支、功能分支、发布分支和修复分支。

1. GitHub Flow：简化的流程，主要依赖于主分支和功能分支。

1. GitLab Flow：为多种场景提供了最佳实践，包括环境分支和版本标签等。这里我给出两张图。

4. 我们公司的"flow"

1. 我个人的项目，只有主分支（master）

小结

狭义的"gitflow" 适用于特定场景，但并非所有项目都适用。

狭义的"gitflow" 不等同于代码提交和项目发布流程，它只是其中一种可能的实践方式。

每个公司都应该根据自己的业务特点，整理和发展适合自己的"业务flow"。

整理这些内容的目的是为了提醒大家，在听到"gitflow"时，要意识到它并不是一个狭义的概念。具体如何实施，还需要团队成员之间的沟通和共识。"gitflow"只是众多流程中的一种，真正的关键在于找到适合自己项目和团队的"flow"。