2
一个产品的不错的git分支模型，该模型应该与另一个第三方产品的版本（以及一个建议的优缺点）一起提供
注意： 我的问题集中在我的特定问题（涉及Liferay）上，但是我希望它对需要在git上维护同一项目的各种版本的人有用。 我在一家为Liferay Portal编写很多插件的公司工作。这些插件（portlet，主题等）通常是可重用的，当然，应该为门户的新版本进行更新。 但是，通常必须将Portlet迁移到Liferay的新版本并维护其先前版本。同样，我们经常必须为某些客户端创建非常特定的自定义，将其添加到“主版本”中没有意义。 这些要求使我们的工作复杂化，但是幸运的是，我们可以进行一些简化。例如，一次只能由一位程序员频繁更新插件。同时在插件中添加两个或多个功能的情况很少见。 现在，我们正在迁移到Gitorious。我们正在尝试为这种情况设想一个分支模型。 我的模特 我建议的是： 每个插件在项目内部的Gitorious中都有自己的存储库。例如，用于显示小猫的portlet将kittens-portlet在liferay-portlets项目内部具有一个存储库。 创建新插件时，请在根据Liferay版本命名的分支（例如lf5.2）上创建它。 每次对插件进行更新时，都会批准该更新并将其部署到生产环境中，并用一个版本（例如lf5.2v1，lf5.2v2等）标记该插件* 每次将插件移植到Liferay的新版本时，我们都会分支最新版本（例如，创建branch lf6.0）。 一旦投入生产，新分支的负责人将收到诸如的标签lf6.0v1。 每次我们必须以客户端特定的方式自定义插件时，都会使用客户端名称创建一个分支（例如，我们将为lf5.2clientcorp客户端“ ClientCorp Inc.” 创建一个分支）。 这是一个不寻常的模型：它没有master分支并且没有很多分支。这就是我假设具有这种模型的存储库的样子： 一位朋友发现此系统相当复杂且容易出错。他提出了出色且受欢迎的Vincent Driessen模型，我发现该模型仍然难以管理和严格遵守纪律。当然，它很棒（并经过测试！），但对于我们的情况似乎太复杂了。 我朋友的模特 然后，他提出了另一种模型：我们将为Liferay版本中的每个插件提供一个存储库（因此，我们将开始创建kittens-lf5.2-portlet，然后再创建kittens-lf6.0-portlet），每个插件都有一个master分支和一个develop分支。该master会随时进行部署。（或者，master和Steve Loshstable所建议的相反）。 这很简单，但是我不喜欢这个系统： 它可能会在一个项目中导致大量的存储库，从而使Gitorious难以浏览。 项目目录的名称是相关的。如果有人将存储库克隆到kittens-lf6.0-portlet目录并使用ant生成WAR（通常），则WAR名称也将是kittens-lf6.0-portlet。kittens-portlet在升级的门户网站中，此portlet的旧版本（例如命名）将被视为不同的portlet（并且可能会丢失）。稍加注意可以避免它，但我宁愿避免它。 同一插件的不同版本将分开维护。我伤了我的心:( kittens-lf6.0-portlet 我认为，这是存储库的丑陋名称。 我怀疑最后两个要点-也是两个更主观的要点-是我不愿意的主要原因。尽管如此，所有四个反对意见仍然成立。 太太，我自己的建议对我自己来说似乎很奇怪，我想知道上面是否有隐藏的错误。OT3rdH git非常强大和灵活，我认为探索它的可能性不应该感到羞耻。 所以，我问： 最好的模型是什么？我的建议？我朋友的模特？现在是传统的Vincent Driessen系统？ 您还建议其他什么分支模型？ 如果您认为我的模型不好，为什么会这样呢？我很想了解缺点和盲点。 *实际上，我更喜欢用这样的版本标记提交，例如，v1但显然git中的标记不在分支范围内-也就是说，我不能在其中添加1 v1标记，lf5.2而在其中另一个标记lf6.0-因此我必须命名科。它是正确的BTW吗？