我们正在尝试采用git-flow实现的成功的Git分支模型.现在,我们正在开发至少两个发布分支,一个用于最新的稳定版本,另一个用于下一个("预览")版本.我不明白为什么所有版本似乎都"线性化"到主人并在那里标记.为什么不在发布分支中标记发行版？为什么大师呢？或者为什么开发分支而不是使用master呢？
mst*_*rap 69
在git-flow模型中,您的"最新发布"版本实际上映射到master,而您的"预览版本"映射到git-flow release分支.它是从实际版本发生时分叉develop并最终合并的master.然后这将成为您的"最新版本",您通常会使用git-flow hotfix分支修复该版本的错误.这样,您master始终代表最新发布版本的最稳定状态.
如果你想修复旧版本的bug或者在那里进行任何其他开发,你将从support适当的提交中分叉一个分支master(你将在那里创建所有版本).support分支仍然是实验性的(根据文档)并没有很好的记录.但是从命令行帮助中可以看到:
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
这些分支刚刚开始,并不打算合并回master也不是develop.这通常很好,因为修复"古代"版本或客户要求在"古代"版本中实现的功能不能或不应该回归master.如果您仍然认为,您希望将修复程序移植到主开发线(由master和表示develop),只需启动一个hotfix,樱桃选择您的更改并完成hotfix.
看起来像一个心理模型,有点过分强调分支.我同意,你可以只标记你发布的提交,而不是将它们合并回master.
不过,画面很漂亮.将所有内容合并回主服务器可以按时间顺序清楚地指示发布,而不是在整个图表中散布版本标记.
不过,我认为这个模型不适用于旧版本中的错误修正.它弄乱了整齐的排序.
回答你的问题:我认为这是一套规则,在某些情况下会产生一个简单的心理模型.从纯粹的技术角度来看,并非所有规则都有意义,但这并不会使它们变坏.心理模型对人类有益.
| 归档时间： |
|
| 查看次数： |
49848 次 |
| 最近记录： |