作为 Git 子模块的单个文件
我正在尝试确定 Git 存储库之间共享代码的最佳实践。
到目前为止,我显然已经遇到了看起来几乎符合要求的子模块。我的项目是一个结构简单的 PHP MVC 框架:
- /app
- core.php
- /core
其中 app
是一个包含特定于应用程序的控制器、模型、视图等的文件夹,而 core
> 包含一般用途的内容,例如登录控制器。 core.php 文件本身是所有请求的全局处理程序。
因此,我在该 MVC 框架的所有部署中共享的代码是 core.php
和 core
。
我可以看到如何将 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您的操作系统支持符号链接,那么您可以设置
core
并core.php
像这样:在每个应用程序存储库中,
base/
目录是使用“base”存储库的子模块或“base”存储库的子树合并。这两种方法都允许您开始在特定应用程序的上下文中更改基本代码,然后将这些更改拉回到主基本存储库中。使用子模块时,您必须小心,在发布任何引用这些新基础提交的应用程序提交之前,必须始终小心地发布新的基础提交(在使用子树合并时,这不是问题,因为每个应用程序都是“扁平”的,并且实际上拥有自己的基础提交副本)根据)。
第三方 git subtree 命令似乎是一个非常好的方法如果您决定不使用子模块,则可以管理子树合并。
子树子
模块
If your OS supports symlinks, then you can set up
core
andcore.php
like this: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
Submodule
子模块是一个 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.
也许您最好将 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.