在任何一个前端团队中，高效协作的基石都是一套清晰、规范的开发工作流。它能确保代码质量、提升开发效率，并让版本发布过程更加平稳。本文将分享一套基于 Git Flow 的实践指南，覆盖从开发到发布的完整生命周期。

一、分支约定：为每个环境定义清晰的角色

一个好的工作流，始于清晰的分支管理策略。我们为不同环境的分支赋予明确的角色：

• master / main 分支：生产环境分支。它永远指向线上最新、最稳定的代码。任何直接提交到该分支的行为都应被禁止。
• release / staging 分支：预发布分支。用于部署到预发布环境，进行上线前的最后回归测试和验收。
• develop / test 分支：测试分支。集成了各个开发分支的功能，用于部署到测试环境，供测试人员进行功能测试。

二、核心工作流：从开发到发布

第一步：开发阶段

1. 创建特性分支 (Feature Branch) 所有新功能的开发都应基于最新的 master 分支创建独立的特性分支。这能确保主干分支的纯净与稳定。推荐的命名规范是 feature/功能描述 或 fix/问题描述，例如 feature/user-login。

2. 统一开发环境 在编码前，请确保本地开发环境（如 Node 版本、npm 源、VSCode 配置等）与团队规范保持一致。环境的一致性是避免“在我电脑上是好的”这类问题的关键。

3. 遵循编码规范 代码风格的一致性至关重要。我们通过自动化工具（如 ESLint, Prettier, StyleLint）来强制执行代码格式规范，确保所有提交都符合团队标准，避免因风格问题在 Code Review 中浪费时间。

4. 规范化提交 (Commit) 我们遵循 Conventional Commits 规范，要求每次提交都附带清晰的类型和说明，格式为 <type>: <description>。例如 feat: add user login functionality。这样做的好处是：

   • 可读性强：无需深入代码，即可了解每次提交的目的。
   • 自动化：能够基于 Commit 历史自动生成版本更新日志 (Change Log)。

第二步：测试阶段

开发完成后，开发者将特性分支推送到远程，并发起一个合并请求（Merge Request / Pull Request）到 develop 或 test 分支。

代码合并后，会自动（或手动）部署到测试环境。此时，测试人员（QA）将介入进行全面的功能测试。如果发现 Bug，开发者将在原特性分支上进行修复并再次提交。

第三步：发布阶段

1. 准备预发布 当一个版本的功能全部测试通过后，相关代码将从 develop 分支合并到 release / staging 分支，并打上一个带有 rc (Release Candidate) 或 staging 后缀的版本号标签（Tag），例如 v1.2.0-rc.1。随后，代码被部署到预发布环境，供产品和设计等相关方进行最终验收。

2. 正式发布 所有验收环节都通过后，就进入了正式发布流程。

   • 将 release 分支的代码合并到 master 分支。
   • 为 master 分支打上正式的版本号标签，例如 v1.2.0。
   • 将 master 分支的最新代码合并回 develop 分支，同步主干代码。
   • 通过自动化部署平台，将 master 分支上打了标签的代码发布到生产环境。

3. 清理工作 发布成功后，建议删除已经合并的特性分支，并清理预发布环境中使用的测试标签，以保持仓库的整洁。

总结

一套定义良好的工作流，是团队战斗力的倍增器。它通过明确的约定和流程，减少了沟通成本和潜在风险，让开发者能更专注于创造价值本身。