解决 GitFlow 的修补程序、错误修复和版本控制方面的问题？

Question

我正在使用 GitFlow 管理一个包含 3 个功能和 2 个版本的应用程序。 版本 1.0.0 将包含功能 1，而版本 2.0.0 将包含功能 2 和功能 3。

这是 1.0.0 版本的 GitFlow 步骤

1. 从开发创建

   Feature 1

   分支。
2. 完成

   Feature 1

   并将其合并回开发中。
3. 确保

   develop 

   稳定并准备好发布。
4. 从

   release 

   创建一个

   develop

   分支（例如release/1.0.0）。
5. 在

   release 

   分支上进行测试并修复所有错误。
6. 在

   release 

   分支上创建发布标签（例如 v1.0.0）。
7. 将应用程序发布到 App Store，版本为

   1.0.0

   。
8. 将

   release 

   分支合并到

   main 

   和

   develop

   。

随着应用程序 1.0.0 在应用商店中发布并且人们正在使用它，

这是第二个版本 2.0.0 的计划：

1. Features 2

   和

   Features 3

   完成了。
2. 合并到

   develop 

   分支。
3. 从

   release 

   创建了

   develop

   分支（例如release/2.0.0）。
4. release/2.0.0 的测试正在进行中

使用 GitFlow 发布 1.0.0 对我来说看起来不错，但我希望针对以下用例使用 GitFlow 解决修补程序、错误修复和版本控制问题：

1. 如果人们报告 1.0.0 中的严重错误需要立即发布新应用程序？
2. 如果人们报告错误，我想修复它并将该错误修复包含在下一个版本 2.0.0 中？

Answer 1

请参阅Atlassian 的 Gitflow 工作流程教程以供参考。还介绍了如何使用

gitflow

工具轻松完成此操作。

如果人们报告 1.0.0 中的严重错误需要立即发布新应用程序？

从主分支创建一个修补程序分支。修复错误。将其合并到 main 和development 中。发布1.0.1.

如果人们报告错误，我想修复它并将该错误修复包含在下一个版本 2.0.0 中？

将其视为正常功能。