这种场景下该采用怎么样的git分支管理策略?
目前开发的项目采用git作为版本管理工具,
平时开发有两个分支,develop和master
在develop上开发,
在master发布正式版本。
目前有这样一种情况:
有一个设计好的功能,由于种种原因,在develop分支上开发完成后不能正常使用,
需要使用另一个补救性的设计方案临时代替,此代替方案需要上线,发布到master里面
当原功能成熟后,再删除这个补救方法,切换回原有的功能
请问我该使用哪种git分支策略?
Answers
推荐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
如果看 A successful Git branching model 吃力,可以看 Juven Xu 的翻译 一个成功的Git分支模型
先帮楼主解决这个问题。
楼主的分支策略不用做特殊处理,按照正常的流程,结合 git 的功能即可处理的很好:
- 首先,在 develop 上开发完成的 commit 后继续提交补救性的代码,以保证 develop 的特性可以正常发布使用。这里楼主提到的“补救性的方案”其实是特性开发的一部分,不算 bugfix 。
- 之后,在测试通过后可以进入 release 流程。如果楼主本来的分支策略中有 release 分支,可以在上一步结束后就打出 release 分支,develop 继续接受新的特性提交。而这次设计的方案和临时性的补救在 release 上接受 bugfix。
- 上面其实都是正常的开发发布流程。后续的设计的开发和补救功能的删除怎么办呢?其实后续的开发其实可以看做改进或者是新特性都可以,正常开发就好。你们可以根据需要在这个改进的过程中任何的节点 revert 当初的补救提交(git revert 命令)。
- revert 补救和“原有的设计”实现后,在按照正常的发布流程发布就好了。
按照我的理解,楼主所说的“原功能”、“补救方案”这些都是正常的代码提交。楼主所困惑的应该是临时补救方案最终要被丢弃(回滚)这个问题如何处理,所以使用上面提到的 git revert 命令应该能满足楼主的预期。这样既能保证所有的对代码库的操作都可以被记录在主干(master、develop)中,也避免了复杂的分支模型等问题。
另外,不知道楼主使用的分支策略是不是 按照
@rsj217
提到的 workflow 来做的。如果 develop 是所有开发人员的主要开发分支的话,我觉得 develop 最好还是不要接受未完成的开发特性直接提交比较好。日常的开发工作,尤其是多特性/分支并行开发的情况下,多个特性分支能避免相互之间的干扰。
回到楼主的问题上来,这个不能使用的设计方案可以继续开发,不要合并到 develop 上去。基于这个分支 checkout 一个补救特性的开发分支,测试完成后合并到 develop 进入发布流程即可。后面的 merge 和 revert 建议还是要的,非迫不得已不要违背流程做特殊处理,而且这样保留了所有的代码commit操作。
可以参考 git workflow
大致就是 从
master
分支
checkout
一个
hotfixes
分支。在
hotfixes
把补救的写好,然后分别
merge
到
master
和
develop
。此时就可以删除这个
hotfixes
分支。
然后再从
develop
分支开发完善你的功能,最后把
develop
分支
merge
到
master
上线。
或许还有更好的方法,仅供参考