Git - how to handle symlinks

Question

What is the correct way to handle symlinks in git?

I have the following structure:

Vendors
  Module A
  Module B
  Module C
App
 Code
   Modules
     Cor         


        

Answer 1

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.

If the symlink points to a directory, git does not store the contents under the symlinked directory.

So there should be no harm in storing symlinks versioned under git for your case.

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).

Answer 2

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.

To decide if something should be included in your git repository or not (symlink or otherwise) consider the following:

• 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.

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:

cd App/Code/Modules
ln -s "../../../Vendors/Module A" "Module A"

Answer 3

@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:

• app/media/bla
• app/media/blubb

I need those folders in the git versioning, without its contents.

On the webserver (same versioning) those folders look like this (symlinks):

• app/media/bla => somewhere entirely else
• app/media/blubb => somewhere entirely else again

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.

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.