大型软件不可避免的需要维护旧版本,新版本的开发工作也在同步进行, 那么就涉及到为所有版本提供漏洞修复补丁的问题。
如果使用手工方法一个版本修复后所有版本同步变更,耗时耗人力; 如果使用 Git 单独开分支,然后 merge 时难免将不想要的变更也带进别的版本。
各位有没有什么更好的办法?
1
ChristopherWu 2018-07-23 16:30:39 +08:00
>如果使用 Git 单独开分支,然后 merge 时难免将不想要的变更也带进别的版本。
一个小分支,一个小功能 or bug fix |
2
hahastudio 2018-07-23 16:38:21 +08:00 1
https://nvie.com/posts/a-successful-git-branching-model/
发布的时候分出一个 branch |
3
loveexception 2018-07-23 16:39:20 +08:00
第一级 大小版本号 改二次
第二级 为每个 BUG 开一分支(有必要热修复的) 从老板本上拆出来。 一个分支 干完了 向二个分支分别合并。(现网,新版本) 第三级 不改 旧版本只改新版本(写到需求单中去。) |
4
corningsun 2018-07-23 16:45:05 +08:00
gitflow 了解一下
|
5
zwy100e72 OP 如果业务需要,需要同时维护多个 Release 版本呢?用语义版本举例:
同时需要维护 v1.9, v1.10, v1.11 版本,其中 v1.11 是开发版本,v1.9 / v1.10 是正式版本 如何避免将相同的 bugfix 同步 3 次呢? @ChristopherWu 您描述的和其他三位意思一致,请看上面这个问题 @hahastudio 很好的文章,图示清晰明了 @corningsun 略有了解,主要是想问上面这个问题 @loveexception 由于是运营商业务,可能没办法做到这点 |
6
zwy100e72 OP @loveexception 这里想表达的是第三级没法做到
|
7
ChristopherWu 2018-07-23 19:11:38 +08:00 1
@zwy100e72 一般我用 `git cherry-pick`, 应该有更好的办法,还望大佬告知。
|
8
GeruzoniAnsasu 2018-07-23 19:27:32 +08:00 1
同 cherry-pick。。。 也觉得没什么好点的办法
|
9
zwy100e72 OP 目前看最好的结果就是 cherry pick 了
这就研究下 |
10
loveexception 2018-07-24 10:28:53 +08:00 1
|