注意： 我的问题集中在我的特定问题（涉及Liferay）上，但是我希望它对需要在git上维护同一项目的各种版本的人有用。

我在一家为Liferay Portal编写很多插件的公司工作。这些插件（portlet，主题等）通常是可重用的，当然，应该为门户的新版本进行更新。

但是，通常必须将Portlet迁移到Liferay的新版本并维护其先前版本。同样，我们经常必须为某些客户端创建非常特定的自定义，将其添加到“主版本”中没有意义。

这些要求使我们的工作复杂化，但是幸运的是，我们可以进行一些简化。例如，一次只能由一位程序员频繁更新插件。同时在插件中添加两个或多个功能的情况很少见。

现在，我们正在迁移到Gitorious。我们正在尝试为这种情况设想一个分支模型。

我的模特

我建议的是：

1. 每个插件在项目内部的Gitorious中都有自己的存储库。例如，用于显示小猫的portlet将kittens-portlet在liferay-portlets项目内部具有一个存储库。
2. 创建新插件时，请在根据Liferay版本命名的分支（例如lf5.2）上创建它。
3. 每次对插件进行更新时，都会批准该更新并将其部署到生产环境中，并用一个版本（例如lf5.2v1，lf5.2v2等）标记该插件*
4. 每次将插件移植到Liferay的新版本时，我们都会分支最新版本（例如，创建branch lf6.0）。
5. 一旦投入生产，新分支的负责人将收到诸如的标签lf6.0v1。
6. 每次我们必须以客户端特定的方式自定义插件时，都会使用客户端名称创建一个分支（例如，我们将为lf5.2clientcorp客户端“ ClientCorp Inc.” 创建一个分支）。

这是一个不寻常的模型：它没有master分支并且没有很多分支。这就是我假设具有这种模型的存储库的样子：

一位朋友发现此系统相当复杂且容易出错。他提出了出色且受欢迎的Vincent Driessen模型，我发现该模型仍然难以管理和严格遵守纪律。当然，它很棒（并经过测试！），但对于我们的情况似乎太复杂了。

我朋友的模特

然后，他提出了另一种模型：我们将为Liferay版本中的每个插件提供一个存储库（因此，我们将开始创建kittens-lf5.2-portlet，然后再创建kittens-lf6.0-portlet），每个插件都有一个master分支和一个develop分支。该master会随时进行部署。（或者，master和Steve Loshstable所建议的相反）。

这很简单，但是我不喜欢这个系统：

1. 它可能会在一个项目中导致大量的存储库，从而使Gitorious难以浏览。
2. 项目目录的名称是相关的。如果有人将存储库克隆到kittens-lf6.0-portlet目录并使用ant生成WAR（通常），则WAR名称也将是kittens-lf6.0-portlet。kittens-portlet在升级的门户网站中，此portlet的旧版本（例如命名）将被视为不同的portlet（并且可能会丢失）。稍加注意可以避免它，但我宁愿避免它。
3. 同一插件的不同版本将分开维护。我伤了我的心:(
4. kittens-lf6.0-portlet 我认为，这是存储库的丑陋名称。

我怀疑最后两个要点-也是两个更主观的要点-是我不愿意的主要原因。尽管如此，所有四个反对意见仍然成立。

太太，我自己的建议对我自己来说似乎很奇怪，我想知道上面是否有隐藏的错误。OT3rdH git非常强大和灵活，我认为探索它的可能性不应该感到羞耻。

所以，我问：

1. 最好的模型是什么？我的建议？我朋友的模特？现在是传统的Vincent Driessen系统？
2. 您还建议其他什么分支模型？
3. 如果您认为我的模型不好，为什么会这样呢？我很想了解缺点和盲点。

*实际上，我更喜欢用这样的版本标记提交，例如，v1但显然git中的标记不在分支范围内-也就是说，我不能在其中添加1 v1标记，lf5.2而在其中另一个标记lf6.0-因此我必须命名科。它是正确的BTW吗？

如果我读得正确的话，分支基本上与您的开发主线只有一次偏离，决不意味着会被合并回主线，主线的进步也永远不会应用于这些分支。唯一的偏差是，需要将适用于分支所基于版本的错误修复程序应用于分支。

现在，答案取决于您的日常工作流程，在任何一个分支上工作的开发人员数量或更改数量都是红色的鲱鱼。我认为您的主要需求是想知道哪些分支可以从主分支更改中获得错误修复更新，为此，我认为将带有分支的组合存储库效率更高，因为它们都集中在一个地方。如果从来不需要交叉授粉，那么单独的存储库将强制执行该任务，但是据我所知，这种情况与您的项目的实际情况不符。

如果您的项目需要将分支合并到开发的主线中，那么Driessen模型将很好地工作，但是您不需要这样做。即使如此，我认为如果您要开发的是有生命的产品，那么维护InDevelopment和StableRelease概念还是有好处的。

因此，总而言之，我认为您的项目将与您的分支模型配合使用，并为您的主线添加一些Driessen。你的旅费可能会改变; 我一直使用“待发布”分支转换为“活动”分支，并使用单独的“下一个发布”进行工作，这些分支都需要在各个点对修复程序和更改进行交叉授粉，因此我的看法可能会有所偏差。

让我感到困惑的是，每个portlet都有自己的存储库（但您的故事可能并不完整）。我个人将为每个项目创建一个存储库。项目通常具有多个portlet，并且都是针对相同版本的Liferay在同一运行中构建的。每个项目都可以是基于不同版本的Liferay构建的现有项目的副本，但是如果差异太大，我只会拆分产品。如果构建适用于Liferay 5.1和5.2，则不会拆分项目。我将使用脚本编写或Maven（或同时使用两者）来使一切正常工作。我将使用Wiki（或Trello）来管理每个产品以及可以针对哪个版本的Liferay进行管理。

顺便说一句：我是Java程序员，Maven专家，Build专家，并且具有Liferay和其他门户服务器（IBM WebSphere和Glassfish）的经验。

但这只是我的0.02欧元。