github - Git branching / workflow model like "nvie gitflow" but without release branches -

is there official documented git workflow nvie's "gitflow" workflow without release branches?

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

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

i guess don't see purpose of release branches, why not tag release master? (maybe that's same thing).

the concept of releases in nvie's branching model (and consequently in git-flow tool) related distinction between branches master , develop. in both, nvie's model , github's model, master supposed 'fit production'. how can ensure that?

why not tag release master?

github's branching model ...

if there few concurrent feature branches, test (and review, other qa want or need) feature branches before merge them master. if significant changes have been merged master (or if changes have — in violation of branching model — been directly committed master) since respective feature branch branched off, merge master feature branch before testing, you're testing integrated state of code.

for this, github's branching model, mentioned chase works fine.

if releasing involves code changes (e.g. bumping version numbers, summarizing changelogs), 1 can directly on master or on dedicated branch. in case, master serves here both, integration , stable branch.

... that's not enough every project

if apply github's branching model in projects many concurrent feature branches, , of latter not short-lived might wish, becomes time you've tested , qaed feature branch (with master merged it), master has changed other merges, you'd have test over. also, going on in project, might difficult know test ensure didn't break of other (maybe merged) features.

nvie's master (stable) ↔ develop (integration) distinction

thus, in busy projects, makes sense have integration / stabilization branch, feature branches merged after respectively having been tested , qaed individually. gives chance test , qa feature implementations again in combination before deciding whether given snapshot of integration shall become release , thereby declared 'fit use'. nvie's branching model calls integration branch develop. master loses integration role , becomes branch deemed-stable snapshots of develop.

but wait — "snapshots" — isn't git tags provide? why separate branch master, then? , again:

why not tag release master[develop]?

only convenience: users (or operators, deployment attachés, ...) not care exact version using, long stable version (or want latest , greatest stable version) can check out master (and pull master update), without having tags there , without having figure out version numbering scheme.

release branches

i thought releases being static clones, not dynamic branches.

they are. release branch not finished release. it's release-in-preparation. it's used bump version numbers, , perform other code changes might not want on feature branches (e.g., because obfuscate actual implementation changes) necessary finished software. (e.g. syncing translation files ui strings needed in application.)

release branches can arbitrarily short-lived. once you're confident release preparations, merge release branch develop , master, additionally placing tag and delete release branch.

do not use release branches maintaining version. that's hotfix , (in more recent versions of git-flow tool) support branches for.

why not releasing commits directly on develop? well, if take longer (or if require cooperation , therefor need publishing of intermediate states), having them on dedicated release branch allows have control on makes release , doesn't, without having block develop further integration of features become ready while you're busy releasing.

release branches in git flow

even if releases require no additional steps, because didn't put version of project repository's content , don't have update used versions of third-party dependencies, , don't postpone updating translations, etc., might worth use release subcommands of git flow, because not forget important rules of nvie's branching model, automating them:

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

if releasing doesn't require cooperation (or doesn't involve dedicated steps @ in project), can

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

without ever pushing release branch before finish deletes again (after merging , tagging, effect you'd want).

to make resulting release visible world, then

git push origin develop master <version released> 

so merges on both branches , new tag sent origin.

if have pushed release branch (be manually or git flow publish release <version number>), instead use

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