Git分支/工作流模型,如"nvie gitflow",但没有发布分支

Question

是否有官方记录的git工作流程就像nvie的"Gitflow"工作流程但没有发布分支？

http://nvie.com/posts/a-successful-git-branching-model/

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

我想我没有看到发布分支的目的,为什么不只是标记一个来自master的发布？(也许这是一回事).

Answer 1

nvie分支模型(以及git-flow工具中)的发布概念与分支master和分支之间的区别有关develop.在nvie的模型和GitHub的模型中,master应该是"适合生产".但你怎么能确保呢？

为什么不只是标记一个主人的版本？

GitHub的分支模型正是这样......

如果并发功能分支很少,您只需在合并它们之前测试(并查看,以及您想要或需要的任何其他QA)功能分支master.如果已经合并了重大更改master(或者如果更改已经 - 违反了分支模型 - 已直接提交master),因为相应的功能分支已分支,请在测试之前合并master到功能分支中,因此您已经在测试集成你的代码状态.

为此,GseHub的分支模型,如Chase所提到的非常好.

如果发布涉及一些代码更改(例如,更新版本号,汇总更改日志),则可以直接在master专用分支上或在专用分支上执行此操作.无论如何,master这里既可以作为集成,也可以作为稳定的分支.

......但这对每个项目都不够

如果你在具有许多并发功能分支的项目中应用GitHub的分支模型,并且后者中的一些并不像你希望的那样短暂,那么当你测试和QAed你的功能分支时(可能已经master合并到它中) ),master已经被其他合并改变了,所以你必须全部测试.此外,随着项目的进展,您可能很难知道所有测试内容以确保您没有破坏任何其他(可能是刚刚合并的)功能.

nvie master(稳定)↔ develop(整合)的区别

因此,在繁忙的项目中,有一个集成/稳定分支是有意义的,其中所有特征分支将在分别经过单独测试和QAed之后合并.这使得有机会再次组合测试和QA功能实现,然后再决定此集成的给定快照是否应成为发布版本,从而声明"适合使用".Nvie的分支模型称之为集成分支develop.master失去集成角色,只是成为视觉稳定快照的分支develop.

但等等 - "快照" - 不正是Git标签提供的那些吗？为什么单独的分支master呢？然后再次:

为什么不只是标记一个版本 主[开发]？

仅为方便起见:用户(或操作员,部署专员,...)谁不关心他们使用的确切版本,只要它是一个稳定的版本(或谁想要最新和最稳定的版本)可以检查出来master(并master进行更新),无需查看有哪些标签,也无需弄清楚您的版本编号方案.

发布分支机构

我一直认为发布是静态克隆,而不是动态分支.

They are. A release branch is not a finished release. It's a release-in-preparation. It's used to bump version numbers, and perform other code changes that you might not want to do on feature branches (e.g., because they obfuscate the actual implementation changes) but that are necessary for the finished software. (E.g. syncing translation files with the UI strings actually needed in the application.)

Release branches can be arbitrarily short-lived. Once you're confident with your release preparations, you merge the release branch to develop and master, additionally placing a tag and then delete the release branch.

Do not use release branches for maintaining a version. That's what hotfix and (in more recent versions of the git-flow tool) support branches are for.

Why not do all those releasing commits directly on develop? Well, if they take longer (or if they require cooperation and therefor need publishing of intermediate states), having them on a dedicated release branch allows you to have control over what makes it into the release and what doesn't, without having to block develop for further integration of features that become ready while you're busy releasing.

Release branches in git flow

Even if your releases require no additional steps, because you didn't put the version of your project into the repository's content and don't have to update the used versions of third-party dependencies, and don't postpone updating your translations, etc., it might be worth to use the release subcommands of git flow, because they help you not to forget important rules of nvie's branching model, by automating them:

• merge the release branch into both, master and develop
• tag the release consistently
• actually delete the release branch when done

If releasing doesn't require cooperation (or doesn't involve dedicated steps at all in your project), you can

git flow release start <version number>
git flow release finish <same version number>

没有在finish再次删除之前推送发布分支(在合并和标记之后,这是你想要的效果).

为了使得到的版本对世界可见,那么

git push origin develop master <version you just released>

以便将两个分支和新标记上的合并发送到origin.

如果您已经推送了发布分支(无论是手动还是使用git flow publish release <version number>),请使用

git push origin :release/<version number> develop master <version number>