Heim > Fragen und Antworten > Hauptteil
目前开发的项目采用git作为版本管理工具,
平时开发有两个分支,develop和master
在develop上开发,
在master发布正式版本。
目前有这样一种情况:
有一个设计好的功能,由于种种原因,在develop分支上开发完成后不能正常使用,
需要使用另一个补救性的设计方案临时代替,此代替方案需要上线,发布到master里面
当原功能成熟后,再删除这个补救方法,切换回原有的功能
请问我该使用哪种git分支策略?
我想大声告诉你2017-05-02 09:22:14
推荐Gitlab flow中的merge request方式
master, develop分支都是不让直接push的
master = production
develop = next release
当有新需求时,建立需求分支 feature/aaa
开发完成后创建 merge request
code review 后合并 feature/aaa
到 develop
分支
上线时合并 develop
分支到 master
发布 master
分支
对于楼主的问题可以这样
基于 feature/aaa
建立新分支 feature/bbb
完成补救工作后合并到 develop
, master
然后上线
继续 feature/aaa
的开发工作,最后合并到 develop
, master
PHP中文网2017-05-02 09:22:14
可以参考 git workflow
大致就是 从 master
分支checkout
一个hotfixes
分支。在hotfixes
把补救的写好,然后分别merge
到master
和develop
。此时就可以删除这个hotfixes
分支。
然后再从develop
分支开发完善你的功能,最后把develop
分支merge
到master
上线。
或许还有更好的方法,仅供参考
PHP中文网2017-05-02 09:22:14
develop(未开发新功能)-> develop(已开发新功能,新功能不可用)-> develop(继续完善到可用)
└───> fix(补救) ╲
└───> master(记得在~1版本打 tag 哦) ╲ merge
master(tag)<────────────────────────────┘ ↘
└───────────────────────────────────────────────> master
phpcn_u15822017-05-02 09:22:14
先帮楼主解决这个问题。
楼主的分支策略不用做特殊处理,按照正常的流程,结合 git 的功能即可处理的很好:
按照我的理解,楼主所说的“原功能”、“补救方案”这些都是正常的代码提交。楼主所困惑的应该是临时补救方案最终要被丢弃(回滚)这个问题如何处理,所以使用上面提到的 git revert 命令应该能满足楼主的预期。这样既能保证所有的对代码库的操作都可以被记录在主干(master、develop)中,也避免了复杂的分支模型等问题。
另外,不知道楼主使用的分支策略是不是 按照 @rsj217 提到的 workflow 来做的。如果 develop 是所有开发人员的主要开发分支的话,我觉得 develop 最好还是不要接受未完成的开发特性直接提交比较好。日常的开发工作,尤其是多特性/分支并行开发的情况下,多个特性分支能避免相互之间的干扰。
回到楼主的问题上来,这个不能使用的设计方案可以继续开发,不要合并到 develop 上去。基于这个分支 checkout 一个补救特性的开发分支,测试完成后合并到 develop 进入发布流程即可。后面的 merge 和 revert 建议还是要的,非迫不得已不要违背流程做特殊处理,而且这样保留了所有的代码commit操作。
高洛峰2017-05-02 09:22:14
姑且说你的补救分支是develop1,上线之后develop1和master会merge到一起变成了新的master,原功能的分支develop等成熟稳定之后merge下新master(很大可能会冲突),把develop1的那部分删掉,测试没问题上线。有点麻烦,可能还有点笨,可是git每次merge都是向前产生了一个新的点,你要是想等develop稳定了把master回退,如果中间有其他发布了,不久丢东西了么。
或许还有更好的方法,仅供参考
我想大声告诉你2017-05-02 09:22:14
如果看 A successful Git branching model 吃力,可以看 Juven Xu 的翻译 一个成功的Git分支模型