Git - 如何处理符号链接
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/15465436/
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
Git - how to handle symlinks
提问by Marty Wallace
What is the correct way to handle symlinks in git?
在 git 中处理符号链接的正确方法是什么?
I have the following structure:
我有以下结构:
Vendors
Module A
Module B
Module C
App
Code
Modules
Core Module 1
Core Module 2
Module A (symlinked to vendors)
Module B (symlinked to vendors)
Module C (symlinked to vendors)
There is a a main App directory which contains all of the core code in the application. Additionally there is a vendor directory that contains modules which get symlinked into the main app directory and therefore integrated.
有一个主 App 目录,其中包含应用程序中的所有核心代码。此外,还有一个供应商目录,其中包含符号链接到主应用程序目录并因此集成的模块。
Importantly, both the vendor directory and the main app directory are both versioned in the same repository.
重要的是,供应商目录和主应用程序目录都在同一个存储库中进行版本控制。
Therefore, should i let git keep storing the symlinks, or find a way to have it ignore symlinks?
因此,我应该让 git 继续存储符号链接,还是找到一种方法让它忽略符号链接?
回答by Martin Atkins
Git can handle symlinks just fine as long as the operating system used by all developers supports them. Since you depend on having these symlinks present I will assume that your development environments all support symlinks.
只要所有开发人员使用的操作系统都支持它们,Git 就可以很好地处理符号链接。由于您依赖于这些符号链接的存在,我将假设您的开发环境都支持符号链接。
To decide if something should be included in your git repository or not (symlink or otherwise) consider the following:
要决定是否应将某些内容包含在您的 git 存储库中(符号链接或其他方式),请考虑以下事项:
- Is it a file generated by some tool or other process in the repository? If so, it's best to ignore it and let each user generate the file, so that they will always have the latest version.
- Is the file specific to a particular user's development environment, or one that is used in all environments? If it's a quirk of a particular user's environment, like a configuration to ignore Emacs backup files, it doesn't belong in the repo. If it's something all developers will need, and/or something that's needed to build the application for production, it should go in the repository.
- 它是由存储库中的某个工具或其他进程生成的文件吗?如果是这样,最好忽略它并让每个用户生成文件,以便他们始终拥有最新版本。
- 该文件是特定于特定用户的开发环境,还是用于所有环境的文件?如果它是特定用户环境的怪癖,例如忽略 Emacs 备份文件的配置,则它不属于 repo。如果它是所有开发人员都需要的东西,和/或构建生产应用程序所需的东西,它应该放在存储库中。
In your case it seems like the symlinks are not generated and they are needed in all environments, so putting them in the repository should be fine.
在您的情况下,似乎没有生成符号链接,并且在所有环境中都需要它们,因此将它们放在存储库中应该没问题。
However, when creating them be sure to create them as relative symlinks rather than absolute symlinks, so that they'll work regardless of where the repository is cloned. The easiest way to do this is to change directory into the Modules directory and create the symlink from there:
但是,在创建它们时,请确保将它们创建为相对符号链接而不是绝对符号链接,这样无论存储库在哪里克隆,它们都可以工作。最简单的方法是将目录更改为 Modules 目录并从那里创建符号链接:
cd App/Code/Modules
ln -s "../../../Vendors/Module A" "Module A"
回答by Tuxdude
Git stores the symlink, just like any other file in its version control - except for a symlink it would only store the information about the path it is symlinking to, and the file type as symlink instead of a regular file.
Git 存储符号链接,就像它的版本控制中的任何其他文件一样 - 除了符号链接,它只会存储有关它符号链接到的路径的信息,以及文件类型作为符号链接而不是常规文件。
If the symlink points to a directory, git does not store the contents under the symlinked directory.
如果符号链接指向一个目录,git 不会将内容存储在符号链接目录下。
So there should be no harm in storing symlinks versioned under git for your case.
因此,为您的情况存储在 git 下版本化的符号链接应该没有害处。
One more thing you need to be aware of with symlinks is that, git would only recreate the symlinks on a fresh clone, not the file or directory it is pointing at. There are chances that the symlinked path would be non-existent (say when using absolute paths).
使用符号链接还需要注意的另一件事是,git 只会在新的克隆上重新创建符号链接,而不是它指向的文件或目录。符号链接路径可能不存在(比如使用绝对路径时)。
回答by ioCron
@Tuxdude Can't agree with you at all with "...then you're doing something wrong". As example, if you need to place a media folder onto a different drive on the webserver or even a NFS then you have to put it outside of the version control. So the contents inside the symlinked media folder won't be accessible through versioning as you explained. But that's a scenario where you have to do it like that. And it's really a pain in the b... My scenario is even more complex (i won't go into detail), what i am actually looking for is to add the subfolders of the symlinked folder into versioning but not its contents, but i need to have a option where i can ignore any changes of the subfolder type itself in git. As example, the basic structure:
@Tuxdude 完全不能同意你的“......那你做错了什么”。例如,如果您需要将媒体文件夹放置在网络服务器或 NFS 上的不同驱动器上,那么您必须将其置于版本控制之外。因此,如您所解释的那样,无法通过版本控制访问符号链接媒体文件夹中的内容。但在这种情况下,您必须这样做。这真的很痛苦......我的场景更复杂(我不会详细介绍),我实际上正在寻找的是将符号链接文件夹的子文件夹添加到版本控制中而不是其内容中,但是我需要有一个选项,我可以忽略 git 中子文件夹类型本身的任何更改。例如,基本结构:
- app/media/bla
- app/media/blubb
- 应用程序/媒体/bla
- 应用程序/媒体/泡泡
I need those folders in the git versioning, without its contents.
我需要 git 版本控制中的那些文件夹,没有它的内容。
On the webserver (same versioning) those folders look like this (symlinks):
在网络服务器上(相同版本),这些文件夹看起来像这样(符号链接):
- app/media/bla => somewhere entirely else
- app/media/blubb => somewhere entirely else again
- app/media/bla => 其他地方
- app/media/blubb => 又是别的地方
The Dev's should have on their local environment just the original versioned structure as explained in the first step (no symlinks). But the webserver has symlinks to different NFS Systems.
开发人员应该在他们的本地环境中拥有第一步中解释的原始版本化结构(没有符号链接)。但是网络服务器具有指向不同 NFS 系统的符号链接。
If anyone has an idea how to solve this i would really appreciate it, because i haven't found any solution to it yet.
如果有人知道如何解决这个问题,我将不胜感激,因为我还没有找到任何解决方案。
The only way i am doing it now is to have a builder that creates the correct / different structure for local environments and the servers and the media subfolders are currently ignored entirely by gitignore. But that can be sometimes tricky / hard to maintain.
我现在做的唯一方法是让构建器为本地环境创建正确/不同的结构,服务器和媒体子文件夹目前完全被 gitignore 忽略。但这有时会很棘手/难以维护。