我有一个Git媒体存储库，我将保存我将在各种项目中使用的所有JavaScript和CSS主文件和脚本。
如果我创建一个位于其自己的Git存储库中的新项目，我如何在我的新项目中使用来自我的媒体存储库的JavaScript文件，这样才能使我不必更新脚本的两个副本我做了改变？
答案 0 :(得分：323)
关键是 git子模块。
开始阅读Git Community Book或Users Manual
的子模块章节假设您有存储库PROJECT1，PROJECT2和MEDIA ...
cd /path/to/PROJECT1
git submodule add ssh://path.to.repo/MEDIA
git commit -m "Added Media submodule"
重复其他回购...
现在，很酷的是，每当你提交更改MEDIA时，你都可以这样做：
cd /path/to/PROJECT2/MEDIA
git pull
cd ..
git add MEDIA
git commit -m "Upgraded media to version XYZ"
这只记录了MEDIA子模块WITHIN PROJECT2现在是XYZ版本的事实。
它使您可以100％控制每个项目使用的MEDIA版本。 git子模块非常棒，但您需要进行实验并了解它们。
有了强大的力量，就会有很大的机会被困在臀部。
答案 1 :(得分：24)
考虑使用subtree而不是子模块，它将使您的回购用户生活更轻松。您可以在Pro Git book找到更详细的指南。
答案 2 :(得分：20)
如果我理解你的问题，你需要做以下事情：
不幸的是，没有最终的解决方案可以满足您的需求，但有些事情可以让您的生活更轻松。
首先，您应该决定一件重要的事情：您是否希望为项目存储库中的每个版本存储对媒体文件版本的引用？例如，如果您有一个名为example.com的项目，您是否需要知道2周前使用哪种style.css，或者最新总是（或大部分）最好？
如果您不需要知道，解决方案很简单：
但是，在大多数情况下，您希望了解此版本控制信息。在这种情况下，您有两种选择：
将每个项目存储在一个大型存储库中。此解决方案的优点是您只有1个媒体存储库副本。最大的缺点是在项目版本之间切换要困难得多（如果你签到不同的版本，你将始终修改所有项目）
使用子模块（如答案1中所述）。这样，您将媒体文件存储在一个存储库中，项目将仅包含对特定媒体存储库版本的引用。但通过这种方式，您通常会拥有许多媒体存储库的本地副本，并且您无法轻松修改所有项目中的媒体文件。
如果我是你，我可能会选择第一个或第三个解决方案（符号链接或子模块）。如果您选择使用子模块，您仍然可以做很多事情来让您的生活更轻松：
在提交之前，您可以重命名子模块目录并将符号链接放到公共媒体目录中。当您准备提交时，可以删除符号链接并删除子模块，然后提交。
您可以将您的一个媒体存储库副本作为远程存储库添加到您的所有项目中。
您可以通过以下方式将本地目录添加为远程目录：
cd /my/project2/media
git remote add project1 /my/project1/media
如果修改/ my / project1 / media中的文件，则可以提交它并从/ my / project2 / media中将其提取，而不将其推送到远程服务器：
cd /my/project1/media
git commit -a -m "message"
cd /my/project2/media
git pull project1 master
您可以稍后删除这些提交（使用git reset），因为您尚未与其他用户共享这些提交。
答案 3 :(得分：2)
我遇到了其他答案所暗示的子树和子模块的问题......主要是因为我使用的是SourceTree，而且看起来相当错误。
相反，我最终使用了SymLinks，这似乎运作良好所以我在这里发布它作为一种可能的选择。
这里有完整的指南：http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
但基本上你只需要在提升的命令提示符下mklink这两个路径。确保使用/ J硬链接前缀。这些内容：mklink / J C：\ projects \ MainProject \ plugins C：\ projects \ SomePlugin
您还可以使用相对文件夹路径并将其放入每个人首次签出项目时执行的蝙蝠。
实施例： mklink / J.或Assets \ TaqtileTools .. \ TaqtileHoloTools
链接文件夹后，您可能需要忽略主存储库中引用它的文件夹。否则你很高兴。
注意我已从其他帖子中删除了我的重复答案，因为该帖子被标记为此帖子的重复问题。
答案 4 :(得分：0)
相当多的项目，本质上是模块化的（更是如此，因为 git 喜欢不太大的存储库），不需要一个成熟的配置阶段：您只需在给定的一组相关文件中布局一些存储库位置，你就完成了。
在这种情况下应该很容易使用这个、这个和这个 repo，这是 git 子模块、子树等之类的尝试完成的。它们能够胜任这项任务，但我认为它们既不容易也不容易出错。
“git repos 中的 Git repos”并不难：请参阅我的 simplest-git-subrepos 示例。