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).
The two primary branches in Git flow are main and develop. There are three types of supporting branches with different intended purposes: feature, release, and hotfix.
Unlike Git-Flow, GitHub-Flow involves no release branches. In the ideas of GitHub-Flow, once a version is ready to go, it can be deployed. Similarly, GitHub-Flow believes that hotfixes are identical to minor feature changes, and their processing methods should be similar.
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?
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 (e.g. 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.
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.
master
(stable) ↔ develop
(integration) distinctionThus, 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.
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 (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.
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:
master
and develop
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>
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With