基于git flow规范的代码版本管理

基于git flow规范

1. 分支命名规范：

• 主分支(master)：

Master分支是仓库的主分支，这个分支包含最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改‌

• master：用于发布稳定版本。
• 开发分支(develop)：

这个分支是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支‌

develop：用于集成所有功能开发。

• 功能分支（feature /xx)：

当你需要发布一个新功能的时候，要基于Develop分支创建一个Release分支，在Release分支测试并修复bug，完成release后，把release合并到master和develop分支‌

命名规范：feature/short-description，例如 feature/user-authentication。

从 develop 分支创建，完成后合并回 develop。

• 发布分支(release/xx)：

当你需要发布一个新功能的时候，要基于Develop分支创建一个Release分支，在Release分支测试并修复bug，完成release后，把release合并到master和develop分支‌

命名规范：release/version-number，例如 release/v1.0.0。

从 develop 分支创建，用于准备发布版本。完成后合并到 main 和 develop。

• 热修复分支(hotfix/xx)：

当我们在生产环境发现新的Bug时候，我们需要基于master分支创建一个Hotfix分支，然后在Hotfix分支上修复bug，完成Hotfix后，我们要把hotfix分支合并回Master和Develop分支‌

命名规范：hotfix/short-description，例如 hotfix/fix-security-bug。

从 main 分支创建，用于紧急修复。完成后合并到 main 和 develop。

2. 工作流程：

1. 新功能开发：

   1. 从 develop 分支创建新的功能分支：git checkout -b feature/new-feature develop。

   2. 完成开发后，发起 Pull Request 合并回 develop。

   3. 代码审查通过后，合并回 develop。

2. 发布新版本：

   1. 创建一个发布分支：git checkout -b release/vX.X.X develop。

   2. 在发布分支上进行版本准备，修复 bug，更新版本号等。

   3. 发布前，合并发布分支到 master 和 develop。

   4. 在 master分支上打一个新的标签。

3. 热修复：

   1. 从 master 分支创建一个热修复分支：git checkout -b hotfix/fix-issue main。

   2. 修复紧急问题。

   3. 发布前，合并热修复分支到 master 和 develop。

   4. 在 master 分支上打一个新的标签。

3. 标签管理：

• 每个发布版本都应该在 master 分支上打一个标签，标签名格式可以是 vX.X.X。

4. 持续集成和自动化：

• 使用持续集成工具，如 Jenkins，来触发自动构建和测试。

• 集成测试通过后，再合并到 develop 或 master 分支。

5. 协同开发：

• 每个开发者在本地使用 feature 分支进行开发，确保功能独立、稳定。

• 定期从 develop 分支拉取最新代码，保持本地代码库同步。

6. 文档：

• 在每个分支上进行开发时，保持相应文档的更新。

• 记录每个版本的变更、发布说明等。