4

我正在为两个机构开发一个非常相同的应用程序。除了单个属性文件中的名称外，所有代码都是 100% 相似的。将来，这两者之间还将共享所需的改进。是否可以在一个 git 存储库下管理两个应用程序的源代码，这样改进和错误修复将非常容易，但会有不同的属性文件？

4

4 回答 4

6

是的，使用分支。

首先提交所有常见的内容，包括相关文件的常见（可能永远不会被实际使用）版本：

(1)

然后，创建一个分支并将更改添加到该文件：

   (2)   <-- customer A
  /
(1)

然后更新回原来的变更集，并使用对同一文件的其他更改创建另一个分支：

   (2)   <-- customer A
  /
(1)
  \
   (3)   <-- customer B

然后你从(1)分支向前发展，合并到你认为合适的各个（客户？）分支：

   (2)---------(6)                        <-- customer A
  /           /
(1)---(4)---(5)---(8)---(9)               <-- development trunk
  \           \
   (3)---------(7)                        <-- customer B

等等

请注意，如果您有很多客户，或者有许多这样小的差异，这可能很快变得笨拙，可能有其他方法来处理差异，例如构建系统将文件替换为构建的一部分，而不是有 N 个分支如此细微的差异。

换句话说，如果差异与每个客户可以访问的品牌和功能等内容有关，构建系统将为每个客户准备不同的可分发产品，这些产品已经配置了正确的文件和配置。这根本不需要额外的分支（除了你应该已经拥有的与开发、测试、生产等相关的分支）。

于 2013-07-06T12:00:48.953 回答
5

在这种情况下，我不会将配置文件置于版本控制之下——只需在自述文件中说明应该提供基于给定示例模板的配置文件，例如数据库凭据。

如果模板更改，您只需更新 README。

于 2013-07-06T12:13:06.547 回答
3

组织这两个项目的两种示例方法：

每个项目都有一个分支。说，master-a和master-b。两者都遵循master字母，只有它们各自有一个额外的提交，其中包含每个项目的自定义属性文件。

更简单的解决方案：根本不将目标属性文件包含在 Git 存储库中。编写一个配置工具，在部署时对属性进行参数化。

于 2013-07-06T12:04:03.620 回答
2

如果只关注单个文件，我发现为每个客户使用一个分支是过分的。

我这样做的方式是忽略配置文件（我们称之为conf.properties ）并对包含默认配置信息的名为conf.properties-dist的文件进行版本控制。
您将部署的代码将是相同的，您只需要使用有关机构的信息来cp conf.properties{-dist,}编辑和编辑conf.properties 。这些步骤通常在第一次部署之后执行一次，并且随着时间的推移保持不变。

于 2013-07-06T17:35:25.387 回答