网站文明建设工程包括,品牌策划公司介绍,网站建设语言都有什么,怎么做网站赚流量Git Flow 分支模型 1.前言
Git Flow 模型#xff08;本文所阐述的分支模型#xff09;构思于 2010 年#xff0c;也就是 Git 诞生后不久#xff0c;距今已有 10 多年。在这 10 多年中#xff0c;Git Flow 在许多软件团队中大受欢迎。
在这 10 多年里#xff0c;Git 本身… Git Flow 分支模型
1.前言
Git Flow 模型本文所阐述的分支模型构思于 2010 年也就是 Git 诞生后不久距今已有 10 多年。在这 10 多年中Git Flow 在许多软件团队中大受欢迎。
在这 10 多年里Git 本身已经风靡全球而使用 Git 开发的最流行的软件类型也更多地转向了网络应用。网络应用通常是持续交付的不会回滚也不需要支持多个版本的软件同时运行。这与原作者在 10 年前写这篇博文时所考虑的软件类型不同。
如果你的团队正在进行软件的持续交付建议采用更简单的工作流程比如 GitHub Flow而不是试图把 Git Flow 强塞进你的团队。不过如果您正在构建明确版本化的软件或者您需要支持软件的多个版本那么 Git Flow 可能仍然适合您的团队。
最后请记住一劳永逸式的通用解决方案是不存在的。考虑一下你自己的项目背景再做决定。 2.Main branches 主要分支
在核心部分开发模型受到了现有模型的极大启发。中心仓库拥有两个无限生命周期的主分支
masterdevelop 每个 Git 用户对位于 origin 的 master 分支都不会陌生。与 master 分支平行的另一个分支叫 develop 分支。
我们把 origin/master 视为主分支在这里HEAD 的源代码总是反映生产就绪的状态。
我们认为 origin/develop 是主分支HEAD 的源代码总是反映下一个版本最新交付的开发变更状态。有人称其为 “集成分支”。每晚的自动构建都是从这里开始的。
当 develop 分支中的源代码达到稳定点并准备发布时所有变更都应以某种方式合并回 master 分支然后标记上发布编号。具体做法将在后面讨论。
因此每次将变更合并回 master 版本时这就是一个新的生产版本。我们倾向于严格遵守这一点因此理论上我们可以使用 Git 钩子脚本在每次 master 版本有提交时自动构建软件并将其发布到生产服务器上。
3.Supporting branches 辅助分支
除了主分支 master 和开发分支 develop我们的开发模式还使用各种辅助分支来帮助团队成员之间的 并行开发、简化功能跟踪、为生产发布做准备以及 协助快速修复实时生产问题。与主分支不同这些分支的生命周期总是有限的因为它们最终会被移除。
我们可能使用的不同类型的分支包括
Feature branches特性分支Release branches发布分支Hotfix branches热修复分支
每种分支都有其特定的目的并受严格的规则约束哪些分支可以作为其原始分支哪些分支必须作为其合并目标。我们稍后将详细介绍它们。
从技术角度看这些分支并不 “特殊”。分支类型是根据我们的使用方式来分类的。当然它们都是普通的 Git 分支。
3.1 Feature branches 特性分支
来自于 develop必须合并回 develop。 分支命名约定只要不用 masterdeveloprelease-*hotfix-* 其他都可以。
feature 分支有时也称作主题分支 Topic branches用于 为即将发布或未来发布的版本开发新特性。在开始开发某个功能时可能还不知道该功能将被集成到哪个目标版本中。feature 分支的本质是只要该特性还在开发阶段它就一直存在但最终会被合并回 develop将新特性添加到即将发布的版本中。
特性分支通常只存在于开发者版本库中而不存在于原始版本库origin中。
1创建 feature 分支
开始开发新功能时从 develop 分支创建分支。
$ git checkout -b myfeature develop
Switched to a new branch myfeature2将已完成的功能并入 develop 分支
已完成的功能可以合并到 develop 分支以便在即将发布的版本中加入这些功能
$ git checkout develop
Switched to branch develop
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop使用 - - no - ff 标志后即使合并可以通过快进执行也会始终创建一个新的提交对象。这样可以避免丢失 feature 分支历史存在的信息并将共同添加该特性的所有提交组合在一起。 在后一种情况下我们无法从 Git 历史记录中看到哪些提交对象一起实现了某个特性而必须手动阅读所有日志信息。在后一种情况下还原整个特性即一组提交确实是个令人头疼的问题而如果使用 - - no - ff 标志就很容易做到。
是的这会多创建几个空提交对象但收益远大于代价。
3.2 Release branches 发布分支
来自于 develop必须合并回 develop 和 master。
分支命名约定release-*。
release 分支支持新生产版本的准备工作。release 分支允许在最后一刻进行校验。此外它们还可以进行小的错误修复并为发布版本准备元数据版本号、构建日期等。在 release 分支上完成所有这些工作后develop 分支就可以接收下一个大版本的功能了。
从 develop 分支分离出新版本分支的关键时刻是 develop 分支几乎反映了新版本的理想状态。至少所有针对即将发布的版本的功能都必须在此时合并到 develop 分支。而针对未来版本的所有功能则不一定它们必须等到 release 分支分支化之后。
正是在 release 分支开始时即将发布的版本才会被分配一个版本号而不是更早。在此之前develop 分支反映的是 “下一个版本” 的变更但在 release 分支启动之前“下一个版本” 最终是 0.3 0.3 0.3 还是 1.0 1.0 1.0 并不清楚。这个决定是在 release 分支启动时做出的并由项目的版本号递增规则来执行。
1创建 release 分支
release 分支是从 develop 分支创建的。例如 1.1.5 1.1.5 1.1.5 版是当前的生产版本而我们即将发布一个大版本。develop 分支已经为 “下一个版本” 做好了准备我们决定将其命名为 1.2 1.2 1.2 版而不是 1.1.6 1.1.6 1.1.6 版或 2.0 2.0 2.0 版。因此我们建立了分支并给 release 分支起了一个反映新版本号的名字
$ git checkout -b release-1.2 develop
Switched to a new branch release-1.2
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m Bumped version number to 1.2
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(), 1 deletions(-)创建新分支并切换到该分支后我们就会提升版本号。在这里bump-version.sh 是一个虚构的 shell 脚本它会更改工作副本中的某些文件以反映新版本。(当然这也可以是手动更改关键是某些文件会发生变化。然后提交被修改的版本号。
这个新分支可能会存在一段时间直到正式发布。在此期间错误修复可能会应用到该分支而不是 develop 分支。严禁在此添加大型新功能。它们必须合并到 develop 分支因此要等到下一个大版本发布。
2完成 release 分支
当 release 分支的状态准备好成为真正的发布版本时需要执行一些操作。首先将 release 分支合并到 master 分支因为 master 分支上的每次提交都是一次新的发布切记。其次必须对 master 分支上的提交进行标记以方便将来引用这个历史版本。最后需要将 release 分支上的修改合并回 develop 分支以便未来的版本也包含这些错误修复。
Git 的前两个步骤
$ git checkout master
Switched to branch master
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2现在发布工作已经完成并打上了标签以备将来参考。你也可以使用 -s 或 -u key 标记对标签进行加密签名。
为了保留 release 分支中的改动我们需要把它们合并回 develop 分支。在 Git 中
$ git checkout develop
Switched to branch develop
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)这一步很可能导致合并冲突甚至可能因为我们已经更改了版本号。如果是这样请修复并提交。
现在我们真的完成了release 分支也可以删除了因为我们不再需要它了
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).3.3 Hotfix branches 热修复分支
来自于 master必须合并回 develop 和 master。
分支命名约定hotfix-*。 hotfix 分支与 release 分支非常相似都是为新的生产版本做准备尽管是计划外的。它们产生的原因是必须立即对实时生产版本中不希望出现的状态采取行动。当必须立即解决生产版本中的关键错误时可以从标记生产版本的 master 分支上的相应标记中分出一个 hotfix 分支。
这样做的好处是团队成员在开发分支上的工作可以继续进行而另一个人则在准备快速的生产修复。
1创建 hotfix 分支
hotfix 分支是从 master 分支创建的。例如 1.2 1.2 1.2 版是当前正在运行的生产版本由于一个严重的错误而造成了很多麻烦。但开发中的更改还不稳定。这时我们可以分离出一个 hotfix 分支开始修复 1.2 1.2 1.2 版本的错误。
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch hotfix-1.2.1
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m Bumped version number to 1.2.1
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(), 1 deletions(-)分支后不要忘记提升版本号
然后修复错误并在一个或多个单独的提交中提交修复。
$ git commit -m Fixed severe production problem
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(), 17 deletions(-)2完成 hotfix 分支
完成后需要将漏洞修复合并回 master 分支但同时也需要合并回 develop 分支以确保下一个版本也包含该漏洞修复。这与 release 分支的完成方式完全类似。
首先更新主版本并标记发布版本。
$ git checkout master
Switched to branch master
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1可以使用 -s 或 -u key 标记对标签进行加密签名。
接下来在 develop 中也包含错误修正
$ git checkout develop
Switched to branch develop
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)这里的规则有一个例外那就是当当前存在 release 版分支时热修复程序的更改需要合并到 release 分支而不是 develop 分支。将错误修正反向合并到 release 分支最终会导致在 release 分支完成后错误修正也被合并到 develop 分支。(如果 develop 中的工作立即需要这个错误修正而又不能等到 release 分支完成那么现在也可以安全地将错误修正合并到 develop 中。
最后删除临时分支
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).4.总结
虽然这个分支模型并没有什么令人震惊的新内容但这篇文章开头提到的 “全局” 图在我们的项目中却非常有用。它形成了一个优雅的心智模型易于理解并能让团队成员对分支和发布流程形成共识。
