如何在另一个存储库中使用 git 存储库?
我有一个 Git 媒体存储库,其中保存了我将在各种项目中使用的所有 JavaScript 和 CSS 主文件和脚本。
如果我在自己的 Git 存储库中创建一个新项目,如何在新项目中使用媒体存储库中的 JavaScript 文件,以便在进行更改时不必更新脚本的两个副本?
I have a Git media repository where I'm keeping all of my JavaScript and CSS master files and scripts that I'll use on various projects.
If I create a new project that's in its own Git repository, how do I use JavaScript files from my media repository in my new project in a way that makes it so I don't have to update both copies of the script when I make changes?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
关键是git子模块。
开始阅读 Git 社区书籍 或 用户手册
假设您有存储库 PROJECT1、PROJECT2 和 MEDIA...
重复另一个存储库...
现在,最酷的事情是,任何时候您提交对 MEDIA 的更改,您都可以执行以下操作:
这只是记录了 PROJECT2 内的 MEDIA 子模块现在版本为 XYZ 的事实。
它使您可以 100% 控制每个项目使用的媒体版本。 git 子模块很棒,但您需要尝试并了解它们。
The key is git submodules.
Start reading the Submodules chapter of the Git Community Book or of the Users Manual
Say you have repository PROJECT1, PROJECT2, and MEDIA...
Repeat on the other repo...
Now, the cool thing is, that any time you commit changes to MEDIA, you can do this:
This just recorded the fact that the MEDIA submodule WITHIN PROJECT2 is now at version XYZ.
It gives you 100% control over what version of MEDIA each project uses. git submodules are great, but you need to experiment and learn about them.
考虑使用 子树 而不是子模块,它将让您的存储库用户的生活变得更加轻松。您可以在 Pro Git 书籍。
Consider using subtree instead of submodules, it will make your repo users life much easier. You may find more detailed guide in Pro Git book.
如果我很好地理解您的问题,您需要以下内容:
不幸的是,对于你想要的东西没有最终的解决方案,但是有一些东西可以让你的生活更轻松。
首先,您应该决定一件重要的事情:是否要为项目存储库中的每个版本存储对媒体文件版本的引用?例如,如果您有一个名为 example.com 的项目,您是否需要知道它在两周前使用了哪个 style.css,或者最新的始终(或大部分)是最好的?
如果您不需要知道这一点,解决方案很简单:
然而,在大多数情况下,您想了解此版本控制信息。在这种情况下,您有两种选择:
将每个项目存储在一个大存储库中。此解决方案的优点是您只有一份媒体存储库副本。最大的缺点是在项目版本之间切换要困难得多(如果您签出到不同的版本,您将始终修改所有项目)
使用子模块(如答案 1 中所述)。这样,您就可以将媒体文件存储在一个存储库中,并且项目将仅包含对特定媒体存储库版本的引用。但这样您通常会拥有媒体存储库的许多本地副本,并且您无法轻松修改所有项目中的媒体文件。
如果我是你,我可能会选择第一个或第三个解决方案(符号链接或子模块)。如果您选择使用子模块,您仍然可以做很多事情来让您的生活更轻松:
在提交之前,您可以重命名子模块目录并将符号链接放置到公共媒体目录。当您准备好提交时,您可以删除符号链接并重新删除子模块,然后提交。
您可以将媒体存储库的副本之一添加为所有项目的远程存储库。
您可以通过以下方式将本地目录添加为远程目录:
如果您修改 /my/project1/media 中的文件,您可以提交该文件并将其从 /my/project2/media 中提取,而无需将其推送到远程服务器:
您可以自由地稍后删除这些提交(使用 git reset),因为您尚未与其他用户共享它们。
If I understand your problem well you want the following things:
Unfortunately there is no ultimate solution for what you want, but there are some things by which you can make your life easier.
First you should decide one important thing: do you want to store for every version in your project repository a reference to the version of the media files? So for example if you have a project called example.com, do you need know which style.css it used 2 weeks ago, or the latest is always (or mostly) the best?
If you don't need to know that, the solution is easy:
In most of the cases, however, you want to know this versioning information. In this case you have two choices:
Store every project in one big repository. The advantage of this solution is that you will have only 1 copy of the media repository. The big disadvantage is that it is much harder to switch between project versions (if you checkout to a different version you will always modify ALL projects)
Use submodules (as explained in answer 1). This way you will store the media files in one repository, and the projects will contain only a reference to a specific media repo version. But this way you will normally have many local copies of the media repository, and you cannot easily modify a media file in all projects.
If I were you I would probably choose the first or third solution (symbolic links or submodules). If you choose to use submodules you can still do a lot of things to make your life easier:
Before committing you can rename the submodule directory and put a symlink to a common media directory. When you're ready to commit, you can remove the symlink and remove the submodule back, and then commit.
You can add one of your copy of the media repository as a remote repository to all of your projects.
You can add local directories as a remote this way:
If you modify a file in /my/project1/media, you can commit it and pull it from /my/project2/media without pushing it to a remote server:
You are free to remove these commits later (with git reset) because you haven't shared them with other users.
相当多的项目本质上是模块化的(更是如此,因为 git 更喜欢不太大的存储库),不需要成熟的配置阶段:您只需在给定的一组相对位置中布局多个存储库,然后您完成了。
在这种情况下,应该很容易使用这个、这个和这个存储库,这就是 git 子模块、子树等试图完成的事情。他们能够胜任这项任务,但我不认为他们可以被认为是容易的,也不容易出错。
“git repos 中的 Git repos”并不困难:请参阅我的 simplest-git-subrepos 示例。
Quite a lot of projects, modular in nature (more so since git favours not-so-big repositories), don't need a full-fledged configuration stage: you just layout a number of repositories within a given set of relative locations and you are done.
In this scenario should be easy to work with this, and this, and this repo, which is what the likes of git submodules, subtrees, etc. try to acomplish. They are up to the task, but I don't think they can be considered easy nor not error prone.
"Git repos within git repos" doesn't need to be difficult: please see my simplest-git-subrepos example.
我遇到了其他答案建议的子树和子模块问题...主要是因为我正在使用 SourceTree 并且它看起来相当有问题。
相反,我最终使用了符号链接,这似乎效果很好,所以我将其发布在这里作为可能的替代方案。
这里有一个完整的指南: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
但基本上你只需要 mklink提升的命令提示符中的两个路径。确保使用 /J 硬链接前缀。类似这样的东西: mklink /JC:\projects\MainProject\plugins C:\projects\SomePlugin
您还可以使用相对文件夹路径并将其放在一个bat中,以便每个人第一次检查您的项目时执行。
例子:
mklink /J .\Assets\plugins ..\SomePlugin
链接文件夹后,您可能需要忽略主存储库中引用它的文件夹。否则你就可以走了。
注意我已从另一篇帖子中删除了重复的答案,因为该帖子被标记为与此帖子重复的问题。
I had issues with subtrees and submodules that the other answers suggest... mainly because I am using SourceTree and it seems fairly buggy.
Instead, I ended up using SymLinks and that seems to work well so I am posting it here as a possible alternative.
There is a complete guide here: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
But basically you just need to mklink the two paths in an elevated command prompt. Make sure you use the /J hard link prefix. Something along these lines: mklink /J C:\projects\MainProject\plugins C:\projects\SomePlugin
You can also use relative folder paths and put it in a bat to be executed by each person when they first check out your project.
Example:
mklink /J .\Assets\plugins ..\SomePlugin
Once the folder has been linked you may need to ignore the folder within your main repository that is referencing it. Otherwise you are good to go.
Note I've deleted my duplicate answer from another post as that post was marked as a duplicate question to this one.