Git分支/工作流模型，如“nvie gitflow”，但没有发布分支

Question

Is there an official documented git workflow just like nvie's "Gitflow" workflow but without the release branches?

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

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

I guess I don't see the purpose of the release branches, why not just tag a release from master? (Maybe that's the same thing).

Answer 1

The concept of releases in the nvie's branching model (and consequently in the git-flow tool) is related to the distinction between the branches master and develop . In both, nvie's model and GitHub's model, master is supposed to be 'fit for production'. But how can you ensure that?

why not just tag a release from master?

GitHub's branching model does just that ...

If there are few concurrent feature branches, you simply test (and review, as well as any other QA you want or need) your feature branches before you merge them into master . If significant changes have been merged into master (or if changes have — in violation of the branching model — been directly committed to master ) since the respective feature branch was branched off, merge master into the feature branch before testing, so you're already testing an integrated state of your code.

For this, GitHub's branching model, as mentioned by Chase works perfectly fine.

If releasing involves some code changes (eg bumping version numbers, summarizing changelogs), one can do this directly on master or on a dedicated branch. In any case, master serves here as both , integration and stable branch.

... but that's not enough for every project

If you apply GitHub's branching model in projects with many concurrent feature branches, and some of the latter not as short-lived as you might wish, it becomes likely that by the time you've tested and QAed your feature branch (with master merged into it), master has already changed by other merges, so you'd have to test all over. Also, with that much going on in the project, it might be difficult for you to know what all to test to ensure you didn't break any of the other (maybe just recently merged) features.

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

Thus, in busy projects, it makes sense to have an integration / stabilization branch, where all feature branches will be merged after respectively having been tested and QAed individually . This gives the chance to test and QA the feature implementations again in combination before deciding whether a given snapshot of this integration shall become a release and thereby declared 'fit for use'. Nvie's branching model calls this integration branch develop . master loses the integration role and just becomes the branch for the deemed-stable snapshots of develop .

But wait — "snapshots" — isn't that exactly what Git tags provide? Why the separate branch master , then? And again:

why not just tag a release from master [develop]?

Only for convenience: Users (or operators, deployment attachés, ...) who do not care what exact version they are using, as long as it is a stable version (or who want the latest and greatest stable version) can just check out master (and pull master to update), without having to look what tags there are and without having to figure out your version numbering scheme.

Release branches

I always thought releases as being static clones, not dynamic branches.

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 (eg, because they obfuscate the actual implementation changes) but that are necessary for the finished software. (Eg 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>

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

To make the resulting release visible to the world, then

git push origin develop master <version you just released>

so that the merges on both branches and the new tag will be sent to origin .

If you have pushed the release branch (be it manually or with git flow publish release <version number> ), instead use

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

Answer 2

There's a pretty good simplified version provided here by Github.

Here is one with tagging that I send to all of our new employees.