使用git实现高效的项目架构

时间:2012-01-13 11:00:08

标签: git git-branch git-merge

首先,让我介绍一个项目的一般架构。

它是分层的。我们为客户开发服务器应用程序。它存储在主服务器

说,本地服务器1,本地服务器2,...,本地服务器n 是不同公司的服务器(主应用程序实例)。每家公司都有一台本地服务器。大多数所有本地服务器都具有相同的功能(例如,核心模块),但每个公司都可以拥有它自己的。作为一个想法,决定通过 git branching 来解决这个问题。

让我们考虑一些情况。

案例1
一家公司(本地服务器x )需要一些仅在该公司中需要的特定功能。遵循我们的分支理念的逻辑,我们执行以下步骤:

  1. 在主服务器上创建git分支
  2. 为该服务器开发所需的功能
  3. 在本地服务器x上创建git branch(分支y)
  4. 将更改推送到主服务器
  5. 在本地服务器x上切换分支y
  6. 切换到主服务器上的主分支
  7. 案例2
    我们开发了一些对所有公司都很常见的功能(核心模块的更改)

    案例3
    我们开发了一些仅对某些公司来说很常见的功能

    想听听有关如何解决“案例2 ”和“案例3 ”的建议。

3 个答案:

答案 0 :(得分:8)

从技术上讲,@ VonC说分支是可行的方法是正确的。

但有一点需要注意。你在这里混合了两种不同的范例。 SCM(git是一种工具)意味着管理源代码及其不同版本。

启用/禁用产品功能是产品管理。从本质上讲,它归结为应用程序的开发和部署。

您尝试做的是将产品的功能管理与版本管理相结合。

这当然是可行的(仅通过SCM)并且根据您的要求,它实际上可能适合您。

然而,在一段时间内,你最终将进入分支/合并汤。它不仅会增加维护和维护每个分支的时间和精力(并保持"主要"以及其他"分支和#34;同步),它也会适得其反在有变化或新功能的时候,您花费更多时间来规划如何使分支机构保持最新状态而不是实际功能。随着时间的推移,新员工对您的分支机构管理技术没有任何了解,并且如果您最终拥有可能因各种原因而想要创建自己的分支机构的分布式团队,那么这会变得更加复杂。

如果我建议,请保留一个版本的应用程序并实施一种机制来启用/禁用"功能"。这将使您的SCM更易于理解,实施和维护更清晰。

中间地带是核心模块的核心分支,然后每个子模块或特征是其独立的分支。任何人都可以安装核心模块,并根据需要/许可,他们可以去安装单独的"功能"来自各自的分支机构。

希望这提供了一些清晰度。如果您有任何疑问,我很乐意详细说明。

答案 1 :(得分:2)

我普遍同意Mrchief。

此外,我想提一下git分支最好用于以下三种情况之一:

  • 在单独的分支上开发一个功能,并在完成后将其合并到主线。
  • 维护旧版本的错误修复程序或安全修复程序
  • 将当前版本的后端口功能更新为旧版本

从长远来看,您应该计划将您的分支合并回主分支或停止它们。让很多分支长时间并排运行并不是一个特别好的主意,因为它们迟早会与主分支(以及相互之间)分离,并且很难确保错误修复或安全修复程序适用于所有分支。

答案 2 :(得分:1)

我们正在讨论具有客户变体的核心模块这一事实意味着git子模块在这里不是一个有效的解决方案:
正在修改同一组文件(对于常见功能,案例2或某些客户端的功能,案例3)。

所以分支是处理这个问题的好方法,除了你需要管理从一个分支到多个分支的合并。
为此,请参阅“How to move bugfixes across branches in DVCS?”等问题。