The concept of releases in the nvie branching model (and therefore in the tool git-flow

) has to do with the difference between branches master

and develop

. Both the nvie model and the GitHub model are master

assumed to be "productionable". But how can you ensure this?

Why not just flag the release from the master?

The GitHub branching model does exactly that ...

If there are multiple parallel feature branches, you simply check (and review, as well as any other parameters you want or need) in your feature branches before merging them into master

. If significant changes were merged in master

(or if the changes were in violation of the branching model - it was directly tied to master

), since the corresponding feature branch was forked, merge master

into a feature branch before testing, so you are already testing the integrated state of your code.

For this, the GitHub branching model, as mentioned by Chase , works great.

If the release involves some code change (for example, dialing version numbers, summarizing changelog), this can be done directly on master

or on a dedicated branch. In any case, it master

serves here both as an integral and stable branch.

... but this is not enough for every project

If you are applying the GitHub branching model in projects with many parallel feature branches, and some of them are not as short as you might wish, it becomes likely that by the time you tested and QAed, master

) master

has already changed by other merges, so you will have to test everything. Also, with a lot going on in the project, it can be difficult for you to know what to check to make sure you haven't broken any other (possibly recently merged) functionality.

nvie master

(stable) & harr; develop

(integration) difference

So in busy projects it makes sense to have an integration / stabilization branch where all feature branches are merged after they have been tested and QAed individually. This provides an opportunity to test and validate the feasibility of implementing features in combination before deciding whether a given snapshot of that integration will become a release and thus declared "usable". The Nvie branch model calls this integration branch develop

. master

loses its integration role and just becomes a branch for considered stable snapshots develop

.

But wait is "snapshot"; isn't that what Git tags provide? Why a separate branch master

, then? And again:

Why not just flag the issue from master [develop]?

Just for convenience: users (or operators, deployment apps, ...) who don't care which version they are using, as long as it's the stable version (or who wants the latest and most stable version) can simply run master

( and pull out master

to update) without thinking about what the tags are or thinking about the version numbering scheme.

Disable twigs

I have always considered releases as static clones, not dynamic branches.

They are. The detached branch is not a finished version. This release is in preparation. It is used to truncate version numbers and make other code changes that you might not want to make in feature branches (for example, because they obfuscate actual implementation changes), but which are necessary for the finished software. (For example, synchronizing translation files with the required UI strings in the application.)

Sheer branches can be arbitrarily short. Once you are confident in your preparation for release, you merge the release branch to develop

and master

by adding a tag and then delete the release branch .

Don't use release branches to maintain the version. ... What the fix is ​​and (in later versions of the tool git-flow

) maintain branches.

Why not do all those who release commits directly on develop

? Well, if they take longer (or if they need collaboration and require publishing intermediate states), having them in a dedicated release branch allows you to control what makes it into release and what doesn't, without having to block develop

for further feature integration that become ready when released.

Release the branches in git flow

Even if your versions do not require additional steps because you have not included the version of your project in the content of the repository and should not update the used versions of third party dependencies and not delay updating your translations, etc., it might be worth using subcommands release

git flow

because they help you remember important rules of the nvie branching model by automating them:

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

If the release does not require collaboration (or does not include highlighted steps at all in your project), you can

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

      

        
        
        
      

    

never pushing a checkout branch before finish

deleting it again (after the merge and tagging you want).

To make the resulting release visible to the world,

git push origin develop master <version you just released>

      

        
        
        
      

    

so that the merges in both branches and the new tag are posted to origin

.

If you have pushed the release branch (whether manually or with git flow publish release <version number>

) then use instead

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