我的问题围绕开发流程以及如何保持分支/子分支、问题和发布的组织。
我读了SO的以下回答:
对在git中创建嵌套分支感到困惑
标签和分支有什么不同?我应该用哪个呢?
但是我仍然不知道组织一个项目的最好方法是什么。例如:
如果我们有三个问题要解决:
- iss43(分支)-修复横幅错误
- iss37(分支)-修复结帐工作流程
- iss50(分支)-改进滚动条
这三个分支都以issue命名,计划发布v1.2.3
此外,我们正在处理另外两个问题,它们有以下问题/分支:
- iss20(分支)-修复支付集成
- iss55(分支)- UI改进
这些被分组到v1.2.4版本
现在的结构是:
Master
-> iss43 (part of 1.2.3)
-> iss37 (part of 1.2.3)
-> iss50 (part of 1.2.3)
-> iss20 (part of 1.2.4)
-> iss55 (part of 1.2.4)
但是,如果项目按照以下方式组织会更有意义:
Master
-> v1.2.3
-> iss43
-> iss37
-> iss50
-> v1.2.4
-> iss20
-> iss55
既然Git没有分支嵌套,那么发布应该是一个分支/标签吗?即
git checkout master
git branch release_v1.2.3
git checkout -b release_v1.2.3 v1.2.3
git branch iss43
git checkout iss43
等于:
Master
-> release_v1.2.3 (with tag v1.2.3)
-> iss43 (issue branch)
-> iss37 (issue branch)
-> iss50 (issue branch)
这有意义吗?或者有更简单的方法来跟踪中小型项目吗?
谢谢。
你第一次是对的,你的第二次方法不合适。
在软件开发中(尤其是在git中),您开发特性并在发布它们时标记一个版本。在你的路线图上为一个特定版本安排的一些功能可能会花费更多的时间,并最终在下一个版本中结束(反之亦然)
事实上,你应该有这样的内容:
git branch -v
master
fix/iss43
fix/iss37
fix/iss50
fix/iss20
fix/iss55
只有当你将fix/*分支合并回master并决定发布时,你才会担心标签(release)。
看看下面的分支模型:git flow或github worklow(你可以在google上找到更好的英文资源)