CODEWITHSUNDEEP
linuxgitubuntugit-clone
bkwdesign
bkwdesign

Reputation: 2097

What's the 'standard' directory location to use when cloning a Git repo onto a LINUX machine

While I spend most of my career on the Microsoft stack as a full-stack web developer - I have, on occasion, made my way into the *NIX side of things.. built out a FreeBSD web server here, played with Caldera Linux once over there, and am currently doing some web deployment using a Google cloud VM that is running Ubuntu...

TL,DR So, if I forked a repo onto my GitHub account- all for the purposes of then cloning it into my Ubuntu server where I'll then compile and run the web application..

What is the professionally expected location that I should put that 'cloned' source code? I googled around a bit to get a better grasp of what the various linux directories are for.. but.. I need a good SO answer... so... where would you put it?

/usr/src/MyGitRepos ..that sounded good to me.. but.. what would you do?

Upvotes: 20

Views: 31062

Answers (4)

alelom
alelom

Reputation: 2998

I would say that the user's home subfolder is the best location choice for cloning a repo. On Linux/Unix/POSIX compliant shells, it is often abbreviated with ~.

Many people choose a location like ~/src/ for cloning their repos.
~ will resolve to /home/[username], and src is a subfolder that you can create there.

Personally, I disagree with people suggesting /usr, /usr/local or /opt for storing git repos, because these folders are intended to store software (binaries, not code):

Additionally, I believe that a git repo cloned copy is not intended to be shared between users and must not be used like that. If sharing of the code is necessary, the repo should be cloned by each user using it, rather than having different users sharing the same folder. Otherwise, conflicts in the modifications to the code will certainly happen soon.

Finally, if disk usage is a concern, it probably means that the repo is used improperly to store large files rather than just source code. Although in theory this can be done, with things like git-lfs which allows to store large assets within a repo, then the work machine should be provisioned to satisfy the disk space requirement for multiple repo clones done by different users.
Instead of storing large assets in the same repo that owns the code is probably advisable to move the large assets into a separate central location, which can be an untracked folder, or a git-lfs repo which can then be cloned only once per machine. In order to simplify the referral to the centralized assets from the code repo, you can use symbolic links placed in the code repo which point to the assets (symbolic links are tracked by git).

Upvotes: 3

viraptor
viraptor

Reputation: 34175

What is the professionally expected location

If as you say you're deploying an app that's compiled from source, then there's no such location. In a professional environment your sources don't go on the servers.

From most professional to "it works" solutions:

  1. Build system packages outside of your production environment. That means you have a repository of both previously deployed versions and have a package manifest including both build and runtime dependencies. That means you can rebuild your app the same way every time. For installation, install the built package. (this applies to deb, rpm, etc.)

  2. Build tarballs with binaries in a predictable environment (developer's box). That means you run (for example, if you're using autotools) ./configure --prefix=/opt/your_app && make install DESTDIR=/tmp/somedirectory - now you can pack the /tmp/somedirectory/opt/your_app contents, copy it to a server and unpack it to /opt/your_app.

  3. Clone it wherever (your home directory), then build, then install in the destination. Popular destinations are /opt/app_name and /usr/local.

The solution depends on how professional the deployment really is, how many servers you've got, have you got test/production environment, etc.

Upvotes: 11

Jokester
Jokester

Reputation: 5617

When it's to be used by a single unix user, somewhere in $HOME is quite reasonable to me. If the repo is meant to be used from other user as well, /opt is considerable.

Upvotes: 3

Nodal
Nodal

Reputation: 353

I wouldn't say there is a standard assumed place, especially if the server is specifically for this application. Putting a folder for it in the /home/user directory should be fine even, or organising it any way you see fit from that point:

/home/user/app-goes-here/app.js

Just keep it simple :)

Upvotes: 3

Related Questions