_My question is focused in my specific problem (which involves Liferay) but I hope it can be useful for anyone who needs to maintain various versions of a same project on git._ I work on a company which writes a lot of plugins for [Liferay][1]. These plugins (portlets, themes etc.) are usually reusable and, of course, should be updated for new versions of the portal. However, it is usual to have to migrate, let us say, a portlet to a new version of Liferay *and* to maintain its previous version. Also, frequently we have to create very specific customizations for some clients, which does not make sense to be added to the "main version". These requisites complicate our work but, fortunately, we can assume some simplifications. For example, the plugins are frequently updated bi only one programmer at a time. It is very rare to have two or more features being added to a plugin at the same time. Now, we are migrating to [Gitorious][2]. We are trying to conceive a branching model for such a scenario. # My model What I proposed was: 1. Each plugin would have its own repository in Gitorious inside a project. For example, a portlet for displaying kittens would have a `kittens-portlet` repository inside the `liferay-portlets` project. 1. When creating a new plugin, create it at a branch named according to the Liferay version (for example, `lf5.2`). 2. Each time a update is made on the plugin, the update is approved and deployed in production, tag the plugin with a version (for example, `lf5.2v1`, `lf5.2v2` etc.)* 3. Every time a plugin should be ported to a new version of Liferay, we branch the most recent version (creating, for example, the branch `lf6.0`). 4. Once in production, the head of the new branch will receive a tag such as `lf6.0v1`. 5. Every time we have to customize a plugin in a client-specific way, we create a branch with the name of the client (for example, we would create a branch `lf5.2clientcorp` for our client "ClientCorp Inc.") This is an unusual model: it would have no `master` and a lot of not-merging branches. This is how I _suppose_ a repository with such model would look like: ![How I suppose my branches would work.][3] A friend found this system rather complex and error-prone. He suggested the excellent and popular [Vincent Driessen model][4], which I found still harder to manage and discipline-demander. It is great (and tested!) of course but seems too complex to our situation. # My friend's model Then he suggested another model: we would have a repository for each plugin in a Liferay version (so we would start creating a `kittens-lf5.2-portlet` and then a `kittens-lf6.0-portlet`), each one with a `master` branch and a `develop` branch. The `master` would be always ready for deployment. (Or it could be the other way around, `master` and `stable`, as suggested by [Steve Losh][5]). This is very simple, but I did not like this system: 1. it could result in an awful lot of repositories in a project, making Gitorious hard to browse. 2. The name of the directory of the project is relevant. If someone clone the repository to a `kittens-lf6.0-portlet` dir and generate the WAR with ant (as usual), the WAR name will be `kittens-lf6.0-portlet` as well. Old versions of this portlet (named `kittens-portlet` for example) would be considered as different (and probably missing) portlets in a upgraded portal. A bit of care can avoid it but I would prefer to avoid it. 3. The different versions of the same plugin would be maintained apart. I break my heart :( 4. `kittens-lf6.0-portlet` is a ugly name for a repository, I think. I suspect the two last points - which are the two more subjective ones, too - are the main reason for my unwillingness. Nonetheless, all four objections stand. OTOH, my own proposal seems strange to myself and I wonder if there is hidden bugs on it. OT3rdH git is so powerful and flexible that I think I should feel no shame on exploring its possibilities. So, I ask: 1. What would be a better model? My proposal? My friend's model? The now traditional Vincent Driessen system? 2. What other branching model would you suggest? 3. If you think my model is bad, why do you think so? I would love to learn what are the drawbacks and blind spots. \* Actually, I would prefer to tag the commit with a version such as `v1` but apparently a tag in git is not scoped in the branch - that is, I could not have a 1 `v1` tag in `lf5.2` and another one in `lf6.0` - so I have to name the branch. Is it correct BTW? [1]: http://liferay.com [2]: http://gitorious.org/ [3]: https://i.sstatic.net/IQ6jZ.png [4]: http://nvie.com/posts/a-successful-git-branching-model/ [5]: http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/#why-default-and-stable-instead-of-default-and-dev