这种场景下该采用怎么样的git分支管理策略?


目前开发的项目采用git作为版本管理工具,

平时开发有两个分支,develop和master

在develop上开发,

在master发布正式版本。

目前有这样一种情况:

有一个设计好的功能,由于种种原因,在develop分支上开发完成后不能正常使用,

需要使用另一个补救性的设计方案临时代替,此代替方案需要上线,发布到master里面

当原功能成熟后,再删除这个补救方法,切换回原有的功能

请问我该使用哪种git分支策略?

git

雨滴 9 years, 6 months ago

姑且说你的补救分支是develop1,上线之后develop1和master会merge到一起变成了新的master,原功能的分支develop等成熟稳定之后merge下新master(很大可能会冲突),把develop1的那部分删掉,测试没问题上线。有点麻烦,可能还有点笨,可是git每次merge都是向前产生了一个新的点,你要是想等develop稳定了把master回退,如果中间有其他发布了,不久丢东西了么。
或许还有更好的方法,仅供参考

貓神八百萬 answered 9 years, 6 months ago

建议参考git工作流 master主分支 develop用于开发 release用于发布新版本 hotfix用于修复线上bug等紧急操作

枪王黑泽翔 answered 9 years, 6 months ago

推荐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

喵美的内裤 answered 9 years, 6 months ago

使用git-flow会对你有帮助,可以用简单的命令,帮你完成创建,完成分支。并且有规范的release,hotfix,feature工作流

袏掱D自甴 answered 9 years, 6 months ago

如果看 A successful Git branching model 吃力,可以看 Juven Xu 的翻译 一个成功的Git分支模型

verui answered 9 years, 6 months ago


 develop(未开发新功能)-> develop(已开发新功能,新功能不可用)-> develop(继续完善到可用)
                 └───> fix(补救)                                 ╲
                           └───> master(记得在~1版本打 tag 哦)      ╲ merge
           master(tag)<────────────────────────────┘               ↘
                 └───────────────────────────────────────────────> master

⑨月D秋雨 answered 9 years, 6 months ago

先帮楼主解决这个问题。

楼主的分支策略不用做特殊处理,按照正常的流程,结合 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操作。

幻想的境界 answered 9 years, 6 months ago

可以参考 git workflow

workflow

大致就是 从 master 分支 checkout 一个 hotfixes 分支。在 hotfixes 把补救的写好,然后分别 merge master develop 。此时就可以删除这个 hotfixes 分支。

然后再从 develop 分支开发完善你的功能,最后把 develop 分支 merge master 上线。

或许还有更好的方法,仅供参考

wxh522 answered 9 years, 6 months ago

Your Answer