Gitflow:修订间差异
标签:2017版源代码编辑 |
标签:2017版源代码编辑 |
||
第40行: | 第40行: | ||
* 完成后必须合并回develop、master分支 | * 完成后必须合并回develop、master分支 | ||
* 命名惯例是release-* | * 命名惯例是release-* | ||
releas分支可以在生产发布之前做最后的一些操作,例如: | |||
* 一些小的bug修复 | |||
* 更新发布产品的元数据,如版本号等 | |||
这样,当release分支创建完成之后,develop分支可以继续下一个发布的开发工作。拉取release分支的时机为,develop分支几乎达到了可以发布的状态,至少所有这次发布的feature需要首先合并完成到develop分支中。如果还有其他的不希望在这次上线发布的feature,必须要等到release分支拉完之后才能合并到develop上。 | |||
<syntaxhighlight lang="bash"> | |||
git checkout -b release-1.2 develop | |||
# 在release分支更新版本号 | |||
./bump-version.sh 1.2 | |||
git commit -a -m "Bumped version number to 1.2" | |||
# merge回master并打tag | |||
git checkout master | |||
git merge --no-ff release-1.2 | |||
git tag -a 1.2 | |||
# merge回develop | |||
git checkout develop | |||
git merge --no-ff release-1.2 | |||
# 删除分支 | |||
git branch -d release-1.2 | |||
</syntaxhighlight> | |||
== hotfix分支 == | == hotfix分支 == |
2024年10月29日 (二) 08:44的版本
git-flow源于2010年一篇A successful Git branching model的文章[1],在这10年间被很多团队采用并成为了一个事实上的“标准做法”。[2]
主分支
在这种模型下,git仓库中有两个分支是一直存在的:
- origin/master(或者main):这个分支上的最新代码永远是production-ready的
- origin/develop:这个分支上的代码永远是下一个发布的最新的交付代码。也可以称为“集成分支”,用于进行每日构建(nightly builds)
当develop分支上的代码达到了上线的标准之后,这些改动就会merge回master分支,并打上release版本号的标签。合并代码到master也就意味着新的产品发布,可以使用web hook来自动进行发布过程:每当master分支有commit的时候自动进行编译、发布等操作发布到生产环境。
辅助分支
除了主分支外,在开发的过程中还有一些辅助分支用来完成开发、发布以及线上问题修复等。这些分支都是临时性的,最终会被从git中移除。
feature分支
feature分支用来开发在未来发布的新功能,但具体在哪个版本进行发布可能还是未知的,它:
- 从develop分支拉取创建
- 开发完成后合并回develop分支(意味着下一次发布会包含这个新功能)
- 或者被丢弃掉(例如发现这个功能影响用户体验)
git checkout -b myfeature develop
git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop
release分支
release分支用来进行发布的准备工作,其:
- 从develop分支拉取创建
- 完成后必须合并回develop、master分支
- 命名惯例是release-*
releas分支可以在生产发布之前做最后的一些操作,例如:
- 一些小的bug修复
- 更新发布产品的元数据,如版本号等
这样,当release分支创建完成之后,develop分支可以继续下一个发布的开发工作。拉取release分支的时机为,develop分支几乎达到了可以发布的状态,至少所有这次发布的feature需要首先合并完成到develop分支中。如果还有其他的不希望在这次上线发布的feature,必须要等到release分支拉完之后才能合并到develop上。
git checkout -b release-1.2 develop
# 在release分支更新版本号
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"
# merge回master并打tag
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2
# merge回develop
git checkout develop
git merge --no-ff release-1.2
# 删除分支
git branch -d release-1.2
hotfix分支
- ↑ https://nvie.com/posts/a-successful-git-branching-model/
- ↑ 作者自己在2020年做了补充说明,认为10年来发生了一些变化,使用Git开发已经成为潮流且更多的应用在向Web APP方向发展。Web应用跟其他的项目有一个比较大的区别就是:Web应用通常持续集成,有问题通常会直接修复了发布而不会回退,不需要同时支持多个版本。这种情况下,作者建议使用更简单的方式如GitHub-flow代替。但同时,作者认为git-flow仍然很好的适用于以下的场景:构建多版本应用(或者说需要同时支持不同的版本)