每当我寻找在团队中正确使用GIT的方法时,总是被引导到git-flow。
一开始我们把这个方案看作是我们的圣经:
时间过去了,我们终于发现将 master
作为稳定分支并打上标签的做法浪费时间。
为什么要给你的稳定版本打上标签,然后再把相同的版本PUSH到master
呢?标签已经存在,你随时可以返回到这个提交版本。为什么还要费心保留这个只包含标签的分支呢?
这里是我们使用的流程,它非常顺畅:
Master: 实际上是我们的开发分支
Release: 我们创建一个发布分支来进行最后的发布测试,如果需要添加修复。
Feature: 我们从Master上创建一个特性分支,然后将其推送到主分支。
实际上,这和git-flow是相同的,只是没有包含稳定分支的分支。
这样做的另一个好处是,master
是 develop
分支。因此,当新团队成员加入项目时,他可以通过克隆项目并使用其master
来更新实际的开发。
在图中:
我的问题是,为什么要使用原始的git-flow五个分支,如果您可以只使用四个分支来实现相同的结果?
develop
分支进行开发,而是使用master
分支,并且使用支持分支来长期维护多个版本的并行开发。 - Géry Ogam