单个文件作为 Git 子模块
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/4170930/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Single file as Git submodule
提问by Will Croft
I'm trying to ascertain best-practices for shared code amongst Git repositories.
我正在尝试确定 Git 存储库之间共享代码的最佳实践。
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:
到目前为止,我显然遇到了子模块,它们似乎 - 几乎 - 符合要求。我的项目是一个结构简单的 PHP MVC 框架:
- /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.
app
包含特定于应用程序的控制器、模型、视图等的文件夹在哪里,而core
包含一般用途的文件夹,例如登录控制器。该core.php
文件本身是所有请求全球处理器。
As such, the shared code amongst all of my deployments of this MVC framework is core.php
and core
.
因此,我在这个 MVC 框架的所有部署中共享的代码是core.php
和core
。
I can see how it is possible to turn core
into a Git submodule, but not core.php
.
我可以看到如何core
变成 Git 子模块,但不是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?
这甚至可能吗?我是否需要重新构建我的框架,使其core.php
驻留在core
文件夹内,以便我可以将整个文件夹作为子模块,还是有更好的方法?
采纳答案by rmk
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.
也许你最好在一个单独的 repo 中维护 core.php 和 core,然后将它用作远程。然后您可以通过将其拉入任何使用它的项目来管理它。为此,只需将新项目作为单独的 git 存储库启动,然后将“核心”存储库作为子树引入。
This chapter shows you how to do it:
本章将向您展示如何操作:
Updated Reference: http://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_mergeOriginal Reference: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
更新参考:http: //git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge原始参考:https: //git-scm.com/book/en/v1/Git-Tools -子树合并
It is a little better for you than the setup advised in the previous section of the book (6.6).
它比本书前一节 (6.6) 中建议的设置对您来说要好一些。
Look at it; it might be helpful.
看它; 它可能会有所帮助。
回答by Chris Johnsen
If you can use symlinks (e.g. you are not using Windows), then you can set up core
and core.php
like this:
如果您可以使用符号链接(例如您不使用 Windows),那么您可以设置core
并core.php
像这样:
# "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.
在每个应用程序存储库中,base/
目录要么是使用“基础”存储库的子模块,要么是“基础”存储库的子树合并。
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 subtreecommand seems like a very nice way to manage the subtree merge, if you decide against submodules.
如果您决定不使用子模块,第三方git subtree命令似乎是管理子树合并的一种非常好的方式。
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
回答by Cascabel
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!
子模块是一个 git 存储库,具有自己的 .git 目录,因此它必须包含在一个目录中。我不相信有任何方法可以轻松解决这个问题。你将不得不以某种方式将你的东西打包到一个目录中 - 如果 core.php 与核心中的东西一起使用,那么将它们放在一个子模块 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.
rmk 的回答,建议你在一个 repo 中完成这一切,使用 core 和 core.php 作为起点是另一个合理的答案。您应该根据预期的工作流程做出决定。如果您计划将核心*内容与使用它的项目分开修改,那么子模块会很好;然后,您可以更新使用它的各种项目中的子模块。如果您想修改核心*内容以适合特定项目,则基线存储库将是不错的选择;然后,您可以从基线存储库中获取更新,将它们与您在项目存储库中所做的更改合并。