作为 Git 子模块的单个文件

发布于 2024-10-03 00:02:29 字数 555 浏览 4 评论 0原文

我正在尝试确定 Git 存储库之间共享代码的最佳实践。

到目前为止,我显然已经遇到了看起来几乎符合要求的子模块。我的项目是一个结构简单的 PHP MVC 框架:

  • /app
  • core.php
  • /core

其中 app 是一个包含特定于应用程序的控制器、模型、视图等的文件夹,而 core > 包含一般用途的内容,例如登录控制器。 core.php 文件本身是所有请求的全局处理程序。

因此,我在该 MVC 框架的所有部署中共享的代码是 core.phpcore

我可以看到如何将 core 转变为 Git 子模块,但不能将 core.php 转变为 Git 子模块。

这可能吗?我是否需要重新构建我的框架,以便 core.php 驻留在 core 文件夹中,以便我可以将整个文件夹作为子模块,或者有更好的方法吗?

I'm trying to ascertain best-practices for shared code amongst Git repositories.

So far, I've obviously come across submodules which seem like they - almost - fit the bill. My project is a PHP MVC framework with a simple structure:

  • /app
  • core.php
  • /core

Where app is a folder containing application-specific controllers, models, views etc. while core contains those of general use, e.g. a login controller. The core.php file itself is the global handler for all requests.

As such, the shared code amongst all of my deployments of this MVC framework is core.php and core.

I can see how it is possible to turn core into a Git submodule, but not core.php.

Is this even possible? Do I need to re-architecture my framework so that core.php resides inside the core folder so I can make the whole folder a submodule, or is there a better way?

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

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

发布评论

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

评论(3

疧_╮線 2024-10-10 00:02:29

如果您的操作系统支持符号链接,那么您可以设置corecore.php 像这样:

# "base" repository layout:
core/
core.app

# each app repository layout:
base/
  core/
  core.php
core -> base/core/
core.php -> base/core.php
app/

在每个应用程序存储库中,base/ 目录是使用“base”存储库的子模块或“base”存储库的子树合并。

这两种方法都允许您开始在特定应用程序的上下文中更改基本代码,然后将这些更改拉回到主基本存储库中。使用子模块时,您必须小心,在发布任何引用这些新基础提交的应用程序提交之前,必须始终小心地发布新的基础提交(在使用子树合并时,这不是问题,因为每个应用程序都是“扁平”的,并且实际上拥有自己的基础提交副本)根据)。

第三方 git subtree 命令似乎是一个非常好的方法如果您决定不使用子模块,则可以管理子树合并。

子树子

git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'

# hook up base
git subtree add --prefix=base [email protected]:me/app_base.git master

mkdir app
# edit app/bar.php

# update base
git subtree pull --prefix=base [email protected]:me/app_base.git master

.
|-- .git/
|   |-- ...
|   `-- ...
|-- app/
|   `-- bar.php
|-- base/
|   |-- core/
|   |   `-- foo.php
|   `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php

模块

git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'

# hook up "base"
git submodule add [email protected]:me/app_base.git base
git commit -m'incorporate base'

mkdir app
# edit app/bar.php

# update base
(cd base && git fetch origin && git merge origin/master)
git add base
git commit -m'updated base'
.
|-- .git/
|   |-- ...
|   `-- ...
|-- .gitmodules
|-- app/
|   `-- bar.php
|-- base/
|   |-- .git/
|   |   |-- ...
|   |   `-- ...
|   |-- core/
|   |   `-- foo.php
|   `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php

If your OS supports symlinks, then you can set up core and core.php like this:

# "base" repository layout:
core/
core.app

# each app repository layout:
base/
  core/
  core.php
core -> base/core/
core.php -> base/core.php
app/

In each app repository, the base/ directory is either a submodule that uses the “base” repository or a subtree merge of the “base” repository.

Both methods will let you start making changes to the base code in the context of a particular app and later pull those changes back into the main base repository. When using submodules you have to be careful to always publish new base commits before publishing any app commits that reference those new base commits (this is not a problem when using subtree merges because each app is “flat” and effectively has its own copy of the base).

The third-party git subtree command seems like a very nice way to manage the subtree merge, if you decide against submodules.

Subtree

git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'

# hook up base
git subtree add --prefix=base [email protected]:me/app_base.git master

mkdir app
# edit app/bar.php

# update base
git subtree pull --prefix=base [email protected]:me/app_base.git master

.
|-- .git/
|   |-- ...
|   `-- ...
|-- app/
|   `-- bar.php
|-- base/
|   |-- core/
|   |   `-- foo.php
|   `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php

Submodule

git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'

# hook up "base"
git submodule add [email protected]:me/app_base.git base
git commit -m'incorporate base'

mkdir app
# edit app/bar.php

# update base
(cd base && git fetch origin && git merge origin/master)
git add base
git commit -m'updated base'
.
|-- .git/
|   |-- ...
|   `-- ...
|-- .gitmodules
|-- app/
|   `-- bar.php
|-- base/
|   |-- .git/
|   |   |-- ...
|   |   `-- ...
|   |-- core/
|   |   `-- foo.php
|   `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php
jJeQQOZ5 2024-10-10 00:02:29

子模块是一个 git 存储库,有自己的 .git 目录,因此它必须包含在一个目录中。我不相信有任何方法可以轻松解决这个问题。你必须以某种方式将你的东西打包到一个目录中 - 如果 core.php 与 core 中的东西一起使用,那么它们放在子模块存储库中是完全有意义的!

rmk 的答案,建议您使用 core 在一个存储库中完成这一切而 core.php 作为起点是另一个合理的起点。您应该根据预期的工作流程做出决定。如果您计划与使用它的项目分开修改核心*内容,那么子模块会很好;然后您可以更新使用它的各个项目中的子模块。如果您想修改核心*内容以适应特定项目,那么基线存储库将是很好的选择;然后,您可以从基线存储库中获取更新,将它们与您在项目存储库中所做的更改合并。

A submodule is a git repository, with its own .git directory, so it must be contained in a directory. I don't believe there's any way to easily get around that. You're going to have to package your stuff into a directory somehow - and if core.php goes with the stuff in core, it makes complete sense for them to be together in a submodule repo!

rmk's answer, suggesting you do this all in one repo, using core and core.php as a starting point is another reasonable one. You should make your decision based on your anticipated workflow. A submodule will be good if you plan on modifying the core* content separately from the projects which use it; you can then update the submodules in the various projects that use it. A baseline repository will be good if you want to modify the core* content to suit a specific project; you can then pull from the baseline repo to get updates, merging them with the changes you've made in the project repo.

思慕 2024-10-10 00:02:29

也许您最好将 core.php 和 core 维护在单独的存储库中,然后将其用作远程库。
然后您可以通过将其拉入任何使用它的项目来管理它。为此,只需将新项目作为单独的 git 存储库启动,然后将“核心”存储库作为子树拉入。

本章向您展示如何执行此操作:

更新的参考:http ://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge
原始参考: https://git-scm.com/book/ en/v1/Git-Tools-Subtree-Merging

这比本书上一节(6.6)中建议的设置对您来说要好一些。

看看它;这可能会有所帮助。

Perhaps you are best off maintaining core.php and core in a separate repo, and then using it as a remote.
Then you can manage it by pulling it into any project it is used. In order to do this, just start the new project as a separate git repo, and then pull in the 'core' repo as a subtree.

This chapter shows you how to do it:

Updated Reference: http://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge
Original Reference: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging

It is a little better for you than the setup advised in the previous section of the book (6.6).

Look at it; it might be helpful.

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