一般按照规范,在生产环境,如果遇到需要新增功能,就开一个feature分支,遇到需要修复bug,就开一个fix分支。
但是,遇到同时要求修复bug,并且也要新增功能,刚好这2个工作,都是同一个人负责的。这时候,还是需要创建一个feature和一个fix分支吗?
第一次用分支来开发项目,感觉,如果同一个人,既要负责新增功能,也要修复bug。这样分支太多,本地是不是要checkout很多代码,会不会很乱?
一般按照规范,在生产环境,如果遇到需要新增功能,就开一个feature分支,遇到需要修复bug,就开一个fix分支。
但是,遇到同时要求修复bug,并且也要新增功能,刚好这2个工作,都是同一个人负责的。这时候,还是需要创建一个feature和一个fix分支吗?
第一次用分支来开发项目,感觉,如果同一个人,既要负责新增功能,也要修复bug。这样分支太多,本地是不是要checkout很多代码,会不会很乱?
现在我是习惯稳定线上分支为master,从master切一个开发分支出来开发,遇到修复bug拉一个fix_bug的分支,修复后推到发布分支进行发布,测试验证没问题后合到master。
如果你觉得乱的话可以用分支所负责的命名分支,分支切换的频率通常比较低,所以不太可能存在经常checkout
5 回答2.8k 阅读
3 回答2.6k 阅读
2 回答2.3k 阅读✓ 已解决
3 回答968 阅读
1 回答1.5k 阅读
典型的 Forking WorkFlow。
这么做是没错的,方便归档和查找。对于一个人来说你觉得麻烦就对了,很多制度上的事儿不是为了节省个别人的时间,而是为了通过规约来降低出错的概率。