84669 人学习
152542 人学习
20005 人学习
5487 人学习
7821 人学习
359900 人学习
3350 人学习
180660 人学习
48569 人学习
18603 人学习
40936 人学习
1549 人学习
1183 人学习
32909 人学习
目前开发的项目采用git作为版本管理工具,
平时开发有两个分支,develop和master
在develop上开发,
在master发布正式版本。
目前有这样一种情况:
有一个设计好的功能,由于种种原因,在develop分支上开发完成后不能正常使用,
需要使用另一个补救性的设计方案临时代替,此代替方案需要上线,发布到master里面
当原功能成熟后,再删除这个补救方法,切换回原有的功能
请问我该使用哪种git分支策略?
推荐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
develop
master
对于楼主的问题可以这样 基于 feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, master 然后上线 继续 feature/aaa 的开发工作,最后合并到 develop, feature/aaa 的开发工作,最后合并到 develop, master
feature/bbb
可以参考 git workflow
大致就是 从 master分支checkout一个hotfixes分支。在hotfixes把补救的写好,然后分别merge到master和develop。此时就可以删除这个hotfixes分支。
checkout
hotfixes
merge
然后再从develop分支开发完善你的功能,最后把develop分支merge到master上线。
或许还有更好的方法,仅供参考
雷雷
先帮楼主解决这个问题。
楼主的分支策略不用做特殊处理,按照正常的流程,结合 git 的功能即可处理的很好:
按照我的理解,楼主所说的“原功能”、“补救方案”这些都是正常的代码提交。楼主所困惑的应该是临时补救方案最终要被丢弃(回滚)这个问题如何处理,所以使用上面提到的 git revert 命令应该能满足楼主的预期。这样既能保证所有的对代码库的操作都可以被记录在主干(master、develop)中,也避免了复杂的分支模型等问题。
另外,不知道楼主使用的分支策略是不是 按照 @rsj217 提到的 workflow 来做的。如果 develop 是所有开发人员的主要开发分支的话,我觉得 develop 最好还是不要接受未完成的开发特性直接提交比较好。日常的开发工作,尤其是多特性/分支并行开发的情况下,多个特性分支能避免相互之间的干扰。 回到楼主的问题上来,这个不能使用的设计方案可以继续开发,不要合并到 develop 上去。基于这个分支 checkout 一个补救特性的开发分支,测试完成后合并到 develop 进入发布流程即可。后面的 merge 和 revert 建议还是要的,非迫不得已不要违背流程做特殊处理,而且这样保留了所有的代码commit操作。
建议参考git工作流 master主分支 develop用于开发 release用于发布新版本 hotfix用于修复线上bug等紧急操作
姑且说你的补救分支是develop1,上线之后develop1和master会merge到一起变成了新的master,原功能的分支develop等成熟稳定之后merge下新master(很大可能会冲突),把develop1的那部分删掉,测试没问题上线。有点麻烦,可能还有点笨,可是git每次merge都是向前产生了一个新的点,你要是想等develop稳定了把master回退,如果中间有其他发布了,不久丢东西了么。 或许还有更好的方法,仅供参考
如果看 A successful Git branching model 吃力,可以看 Juven Xu 的翻译 一个成功的Git分支模型
使用git-flow会对你有帮助,可以用简单的命令,帮你完成创建,完成分支。并且有规范的release,hotfix,feature工作流
推荐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
,feature/aaa
建立新分支feature/bbb
完成补救工作后合并到develop
,master
然后上线继续
feature/aaa
的开发工作,最后合并到develop
,feature/aaa
的开发工作,最后合并到develop
,master
可以参考 git workflow
大致就是 从
master
分支checkout
一个hotfixes
分支。在hotfixes
把补救的写好,然后分别merge
到master
和develop
。此时就可以删除这个hotfixes
分支。然后再从
develop
分支开发完善你的功能,最后把develop
分支merge
到master
上线。或许还有更好的方法,仅供参考
雷雷
先帮楼主解决这个问题。
楼主的分支策略不用做特殊处理,按照正常的流程,结合 git 的功能即可处理的很好:
按照我的理解,楼主所说的“原功能”、“补救方案”这些都是正常的代码提交。楼主所困惑的应该是临时补救方案最终要被丢弃(回滚)这个问题如何处理,所以使用上面提到的 git revert 命令应该能满足楼主的预期。这样既能保证所有的对代码库的操作都可以被记录在主干(master、develop)中,也避免了复杂的分支模型等问题。
另外,不知道楼主使用的分支策略是不是 按照 @rsj217 提到的 workflow 来做的。如果 develop 是所有开发人员的主要开发分支的话,我觉得 develop 最好还是不要接受未完成的开发特性直接提交比较好。日常的开发工作,尤其是多特性/分支并行开发的情况下,多个特性分支能避免相互之间的干扰。
回到楼主的问题上来,这个不能使用的设计方案可以继续开发,不要合并到 develop 上去。基于这个分支 checkout 一个补救特性的开发分支,测试完成后合并到 develop 进入发布流程即可。后面的 merge 和 revert 建议还是要的,非迫不得已不要违背流程做特殊处理,而且这样保留了所有的代码commit操作。
建议参考git工作流 master主分支 develop用于开发 release用于发布新版本 hotfix用于修复线上bug等紧急操作
姑且说你的补救分支是develop1,上线之后develop1和master会merge到一起变成了新的master,原功能的分支develop等成熟稳定之后merge下新master(很大可能会冲突),把develop1的那部分删掉,测试没问题上线。有点麻烦,可能还有点笨,可是git每次merge都是向前产生了一个新的点,你要是想等develop稳定了把master回退,如果中间有其他发布了,不久丢东西了么。
或许还有更好的方法,仅供参考
如果看 A successful Git branching model 吃力,可以看 Juven Xu 的翻译 一个成功的Git分支模型
使用git-flow会对你有帮助,可以用简单的命令,帮你完成创建,完成分支。并且有规范的release,hotfix,feature工作流