On: Why aren't you using git-flow?

[Vitaly]

its actually very easy.

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

[joshd → Vitaly]

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.

[eru → joshd]

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.

[chousuke → joshd]

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.