多个模块(主题)的推荐工作流程

发布于 2024-10-12 13:13:19 字数 1113 浏览 5 评论 0原文

我有一个应用程序(cms),其结构如下:

BASE:
    /application/
    /public/
        themes/
           default/
           mobile/

这是我们所有项目的基础中央存储库。然后项目就有了自己的皮肤: (基于 /default/ 主题

CLONE1:
    /application/
    /public/
        themes/
           default/
           mobile/
           own/
           ...
           own-theme-12/

(此应用在默认主题的基础上有 12 个自定义主题)。

整个事情就是维护应用程序并使所有克隆与基地保持同步。

现在,我们将 BASE 添加为远程存储库:

(/clone1/)$ git remote add base-repo /path/to/base.git

然后在需要时拉取更新:

(/clone1/)$ git pull base-repo develop

当修改 /application 中的 .php 文件时,一切正常。当我们修改 BASE 存储库中的 default 主题中的文件(例如 reset.css 中的拼写错误)时,问题就开始了。我们需要对 CLONE1/default 主题和所有 CLONEx/own-x/ 主题进行这些更改。

当然,需要一些 bash 脚本来告诉在哪里复制和提交更改,但是如何在没有合并冲突的情况下保持整个内容同步?

我们使用git flowdefaultmobile 主题目前尚未位于单独的分支中。我们需要他们吗?我们还没有使用子模块。

组织此工作流程的方法有很多种,但您会选择哪一种作为最佳方法?

I have an app (cms) which structure is like this:

BASE:
    /application/
    /public/
        themes/
           default/
           mobile/

This is a base, central repository for all our projects. Then the projects get their own skin:
(which are based on /default/ theme)

CLONE1:
    /application/
    /public/
        themes/
           default/
           mobile/
           own/
           ...
           own-theme-12/

(this app has 12 custom themes based on the default one).

The whole thing is about maintaining the applications and keeping all the CLONES up to date with the BASE.

Now, we add BASE as remote repo:

(/clone1/)$ git remote add base-repo /path/to/base.git

Then pull for updates when needed:

(/clone1/)$ git pull base-repo develop

When the .php files in /application are modified everything works great. The problem begins when we modify the files in default theme in BASE repo (e.g. typo in reset.css). We need those changes in CLONE1/default theme and all of the CLONEx/own-x/ themes.

Of course some bash script will be needed to tell where to copy and commit the changes, but how to keep the whole thing in sync without merge conflicts?

We use git flow. The default and mobile themes are not in the separate branches by now. Do we need them to be? We don't use submodules yet.

There are many ways to organize this workflow, but which would you choose as the optimal one?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

甜中书 2024-10-19 13:13:19

您可以使用 git-subtree 来帮助解决此类问题。基本上,您正在做的是基于上游应用程序构建自定义应用程序,并且您的自定义应用程序有两种更改:应用程序修复和特殊主题。您想要获取应用程序修复并将其发送到上游,但您不想将特殊主题发送到上游。

如果您在顶层创建两棵子树:一棵用于您的上游应用程序,一棵用于您的主题,那么您可以使用 git-subtree 拆分/连接它们。从上游继承的主题可以从应用程序目录符号链接到主题目录。所以你会得到这样的结果:

    /app/code/*.php
    /app/themes/default/
    /app/themes/mobile/
    /themes/default -> ../app/themes/default
    /themes/mobile -> ../app/themes/mobile
    /themes/own-1/

当你想向上游发送应用程序更改时,你会执行类似的操作

    git subtree split --prefix=app --rejoin

You can use git-subtree to help with this sort of problem. Basically, what you're doing is building a custom app based on an upstream app, and your custom app has two kinds of changes: app fixes and special themes. You want to take the app fixes and send them upstream, but you don't want to send your special themes upstream.

If you create two subtrees at the toplevel: one for your upstream app, and one for your themes, you can then split/join them with git-subtree. The themes inherited from the upstream can be symlinked from the app directory into the themes dir. So you get something like this:

    /app/code/*.php
    /app/themes/default/
    /app/themes/mobile/
    /themes/default -> ../app/themes/default
    /themes/mobile -> ../app/themes/mobile
    /themes/own-1/

When you want to send app changes upstream, you do something like

    git subtree split --prefix=app --rejoin
姜生凉生 2024-10-19 13:13:19

考虑到应用程序需要这些主题目录才能运行,它们应该保留为目录,而不是分支。
您无法将多个分支部署到生产中(您可以从一个或另一个分支中选择版本,而不是全部)。您可以部署多个目录,从而允许应用程序在不了解 SCM 的情况下运行。

对于其余部分,脚本作为 合并驱动可以:

  • BASE/default的内容合并到local/default
  • 检查是否有相同的文件(例如reset.css 存在于其他目录中,并开始报告其相同的演变)。

我没有确切机制的细节,但我怀疑合并驱动程序是传播更改的一个很好的入口点。

Considering the application needs those theme directories to function, they should be kept as directory, not as branches.
You cannot deploy several branches into production (you select version from one branch or another, not all of them). You can deploy multiple directories, allowing the application to run without having any knowledge about an SCM.

For the rest, a script executed as a merge driver could:

  • merge the content of BASE/default to local/default
  • check if the same file (like reset.css exists in other directories and start reporting the same evolutions on it as well).

I don't have specifics on the exact mechanism, but I suspect a merge driver is a good entry point to propagate the changes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文