Git flow is a great tool as a starter to teach people what a reasonable git workflow is. Once you understand got better, you may find it a bit constraining.
Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense.
EDIT: Please not I am not suggesting that you not do feature branching. That is an awesome and compelling feature of git. I just don't see the need for a second branch just for developing in general in. That's what master has traditionally been for.
If you develop directly in master, then how can you go back and fix a severe bug in the version of the code that is in your production site without having to revert all the in-progress development changes or risk introducing them into the bugfix? I believe this is the intent of not working in master.
If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new branch from it? I could be wrong but I thought tags in git were basically just read-only and informational - can you start work from them?
There's a psuedo-branch in master, which is "everything since the latest commit that has been pushed out". (This is my own terminology, so don't go Googling for it.) This is the branch that becomes "real" once pushed to the public, and that's when you can no longer rewrite the history without hurting things.
If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in), it's really easy to deal with. You branch from master, re-checkout master, and git reset --hard back to the public psuedobranch. And it is as if you had a branch all along.
I play the same game with git svn sometimes, except the psuedobranch is the "stuff that has not yet been committed to SVN" and it's a lot more clear where the cutoff is. I won't pretend this is perfect, but it does work.
(The problem I have with branching off for absolutely everything is that I find it easy to end up with too many branches to remember what's what. Granted, I'm the team lead and I may be more prone to that than a team member with more defined tasks.)
There's no need for any custom terminology: Your master branch isn't a pseudo-branch. It's just another branch that happens to live in your local repository and shares the same name as the remote repository's branch that it tracks.
You develop on master. if you need s 'stabilisation' phase, when you only do bugfixes you can do that on a release branch. Or if you usually deploy the latest you can just tag the version that you deploy. If you want to just fix something from the currently deployed version you can create a 'hotfix' branch out of the tagged release version, do the fix, deploy, merge the hotfix branch into master and delete it:
git branch hotfix v1.2.3
git co hotfix
# do the fix
git tag v1.2.4
# deploy
git co master
git merge hotfix
git branch -d hotfix
Is there a reason to delete the branch? I don't think I've ever tried to delete a branch in subversion. I imagine it's possible, and can be reversed if necessary, but goes against my thinking of the repository as a canonical log of all development.
Since branches are supposed to be mutated all the time, and don't keep any history about where they were earlier, it's quite reasonable to delete branches.
Commits are what's fixed. Branches are basically just mutable pointers to commits.
No relevant information is lost. You're basically only deleting the reference, which is only a name. As long as you don't explicitly destroy the commits (eg. with a squashing merge or a rebase) the branch will still exist in the repository structure. The commits won't be GCd because they're merged to another branch which has an explicit reference (master).
You can at any time go back to it as long as you know the SHA-1 identifier for the head commit you want. Because of this, there's little reason to keep temporary refs cluttering the ref namespace.
If you really want to keep references to everything, a "git attic" tool exists which allows you to move branch refs out from the main ref namespace into a normally invisible (ie. doesn't show up in git branch etc.) namespace.
Going a bit further, when you create a branch, what you're specifying is a starting point for that branch which will be a commit. The commit may be referenced via a tag, as the head of a branch (when you give the branch name or the head of the current one by default), or by the commit itself.
It's not hard (not claiming it's sensible, but still). Do gitk --all, walk back to the tag, right click and create a new branch. This is even possible if there was no tag (just a recognizable revision), or if you want to create a tag retroactively.
If you are using git-flow, this should probably be done in a hotfix branch, so that when you are done, finishing your hotfix merges directly to master and develop. Without a hotfix you would have to manually merge master back into develop.
Master exists as a pristine releasable code base. Develop is the main branch for working on things, and branching usually happens from there. Having master and develop lets you keep developing on your project while having a frozen deployable branch master in this case.
My question is, why is this (develop/master) better than master/release branches? Or master/qa/production? Or do you view that as just an arbitrary choice of names (since there's nothing special about the master branch in git)?
I would prefer not calling any branch master when using a specific scheme like this. It's confusing. Master of what? The master development branch? The master release branch? Better to name each branch specifically.
The master/develop model gives you a pointer to the latest release for free. The pointer is called master.
Without the 'extra' develop branch, you have to remember or lookup the name of the latest release if you want to make a hotfix, or keep an extra tag for it, in which case the two models are the same.
And on a related note, You May Be Getting Old if you increasingly hear statements like, "I don't know how anybody ever did X without having Y!" and you have direct memories of having did X quite successfully for 10-20+ years without, as you may have guessed, having Y. Because Y didn't exist for most of that time!
If you are doing this style exactly without git flow, you don't gain a whole lot. It is great if you are working with a team then it forces everyone to work the same way and is very clear what you do in each situation. One of my favorite features of git-flow is housekeeping, for features when you close them it merges to develop and destroys the branch, when you do a hotfix it merges to master and develop and destroys the branch. When you release it creates a tag with whatever version you specify, and you can work on that until you are happy with the state of release, then when you push tags you will have a nice snapshot of your last deploy.
Would a single member of the team (the release manager) be doing it all though, and the rest of the team would only be pushing to the development branch? The release manager would maybe pull for hotfixes, but it would always be the release manager doing the work (or his proxy).
While I understand your concern, a feature of gitflow IMO is that you can switch between git and gitflow as you wish. Personally, I like the constraints that gitflow creates because it simplifies the process of pushing out releases.
Since time is my number one constraint right now, I'm taking advantage of every tool that makes me more productive. Yes, you can certainly implement the workflow with vanilla "git" but if you're going to follow the workflow model, why not use a tool that excels at that workflow? especially when said tool allows you to see what it's doing.
Our team uses this with great success. To take this a step further we name our features in conjunction with features in our project management tool. git flow feature start visitor_can_sign_in_812381 This gives us a nice mapping of feature branches to actual features. The one thing to be aware of with git flow is that the author is more on the merge side than on the rebase side. So closing features just involves merging on top of the develop branch. This hasn't raised many problems for our team though.
Regarding rebasing, the first commenter at the bottom of the linked article mentioned he prefers rebasing to merging, and referenced a blog post of his explaining why:
Has anyone used git-flow with an existing repo? It seems like existing branches could just be renamed from "myfeature" to "feature/myfeature", etc. but I wonder if others have been down this road and have run into issues.
I've done some playing around with a dummy "existing" repo and it seems to adapt well. Upon "git flow init" it identifies existing branches and proceeds with the questionnaire in the article above associating.
Here's a gist I created showing how an existing repo (although very basic) can be adapted to use git-flow - http://gist.github.com/538326
also, if you want to fiddle with the options after you set it up with git flow init, just go to the .git/config file and change it there :)
when in doubt, look at stuff in a repo's .git/ to find what you wanna fiddle with. unless of course you want to look at user wide config file at ~/.gitconfig
One of the original intents of the git project was to create an "SCM toolkit" where other people would use git to build their own little interfaces on top of it.
Then everyone just used git. It's interesting to see this dream come to a small amount of fruition.
Because most of us don't need a branching model this complex, and if we do doing the equivalent thing with "git checkout" is trivial compared to actually managing all those branches.
This sounds like a great tool for developers who are starting out in git, but it is even better for those familiar to it because it makes our life easier.
If there's one thing I've learned in 15+ years of build/release/scm engineering, it's that there is no one-size-fits-all branching model or workflow. git-flow is a nice set of tools for one workflow/branching model, but it should not be confused with a silver bullet.
It just appears to be a fancy-pants way of creating branches for you. Plenty of projects (e.g. Git itself) use a similar development model without using git-flow.
Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense.
EDIT: Please not I am not suggesting that you not do feature branching. That is an awesome and compelling feature of git. I just don't see the need for a second branch just for developing in general in. That's what master has traditionally been for.
And yes, you can branch and redo tags at any time. If you don't know this, you probably don't understand git's underlying model very well. Time to read up: http://www.google.com/search?q=explanation+of+git+internals