Git Branching model

So the branching model I usually use is similar to the following:

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

However, I am currently employed where they are creating a new branch for every new release. For example, they are merging 1.0 out of master at which point master becomes dead. When they needed to start 1.1 development they would merge 1.1 out of 1.0. W开发者_StackOverflow中文版hen they are finished on 1.0, they would deploy it into production and that branch would essentially become dead. You can do the normal and merge off of the release branches for major features and merge back into it when finished.

The only thing that I can think of that makes this extremely useful is if you for some reason are doing a hotfix on something other then the previous release. Because that branch is always there you could go back to it and make changes and commit a hotfix. (or create a branch off of it and merge it back in). They are tagging releases ect...

This seems really unintuitive to the way git was designed as you don't really have a main branch.. your main branch is the last release you merged off of the previous branch. I think this may work better for multiple lines of development.. If you are working on 3 releases at once. Is there any issues that could come up from using git this way?

There is functionally no difference between leaving your release branches dangling around, and merging them back into master and tagging your release. Both branches and tags are simply pointers to a single commit. The benefit to tagging various commits in your master branch as specific releases is you don't have a bunch of branches cluttering the output of git branch, and instead you can clearly request a list of branches with git tag.

I suspect your coworkers are stuck thinking of branches as real things, when they are fundamentally just a specific kind of tag (or rather, tags and branches are both just refs).

The only thing that I can think of that makes this extremely useful is if you for some reason are doing a hotfix on something other then the previous release.

You can just as easily check out a tag and perform a fix.

Is there any issues that could come up from using git this way?

Not really, besides becoming very confused when you have a hundred branches displayed by git branch. Git works regardless of how you manage your branches.

I'm assuming that you have something similar to this:

master
      `->1.0----(release)
          |       |
           `-----.-->1.1----(release)
                       |      |
                        `---->1.2(release)
                               |
                                `--->2.0

Technically, really is no problem with it. In effect, the latest numbered branch is your master. However, it does break with convention which specifies that master is usually where the real code lives. So maximum you might need to do some explaining to consultants you call in or any companies you outsource to.

As long as your branches are merged nicely in some way to whatever the latest branch is, you're good. If not, if someone deletes a branch that has dangling commits, you've lost that work when git does its garbage collection.