I have a few repos on GitHub. Up until now, I've used a single machine (a Mac) to host the local version of of these repos; i.e. they are located in the folder /Users/seamus/Documents/GitHub on the Macintosh HD for this Mac. Eeach repo has a sub-folder. Straightforward and simple to maintain for one user and one machine.

But I'm "branching out" a bit... I now have 3 Macs, an Ubuntu desktop, a few Raspberry Pis and I work on projects that are tied closely to a particular machine. For example, I have set up the IDE for my RPi Pico ucontroller on the Ubuntu box, whereas my Mac-related projects are on one of my Macs - which one depends upon whether the project is "vintage" or "current". And this may be important: I am the only "local person" working on these repos - there is no "team".

In summary, it has become awkward to have the local repo located on the Mac HD of one of my Macs. A potential solution would be to move my local Mac HD-based repo to my NAS drive - a Synology unit. I can mount a share on the Synology from all of my machines, and (it seems to me) this would solve my immediate problem by allowing me to work on any of my repos from any of my machines.

AFAICT the NAS-hosted local repo should work fine for my current situation (1 user, several repos). But I'm not proficient with git, so I wanted to ask if there are any obvious problems with this setup - or if there's a better way to accomplish my objective?

CodePudding user response：

Yes, this is possible, intended usage of git, and even pretty straightforward.

You just need to make sure that the repositories on the NAS are initialized as bare repos. A bare repo is basically the contents of the .git directory, containing your entire project history, but without any currently checked-out working copy. This is what allows you to push to it.

For example:

# Assuming your NAS is mounted on /mnt/nas
$ cd /mnt/nas

# Initialize bare repository in /mnt/nas/some_project
$ git init --bare some_project

# Assuming your working copy lives in ~/some_project
$ cd ~/some_project

# Add the NAS repo as a remote, and push all branches to it
$ git remote add origin /mnt/nas/some_project
$ git push --all

If you have ssh access to your NAS, you can even skip the mounting step and use username@hostname:/path/on/nas/some_project as the remote. But you can't git init it in that way.

CodePudding user response：

It is usually unwise to mount a foreign (network-attached) drive as a file system and use it that way, i.e., as a shared drive, to host a Git repository. The reason for this is that Git depends very heavily on POSIX semantics:

• that creating a file with O_CREAT | O_EXCL works for creating lock files;
• that renaming a file with a single rename system call is atomic;

and various other things that often don't hold true for NFS, Samba, and other network-based file systems. (But if you're careful to only use one client at a time and wait for all traffic to finish before moving to another client, you could consider risking that. Almost all the POSIX-semantics-failure cases have to do with parallel use.)

Using a network device as a (pseudo) disk drive, for instance with iSCSI, usually does work. But in this case you lose any advantages you were hoping to gain by using the NAS box.

If the NAS box supports Git, ssh, or HTTPS protocols, however, Thomas's answer works fine: you have the NAS box provide a local bare clone, and you clone that local clone to each of the local machines on which you'll work. You can push back to that bare clone, and—assuming the NAS box is sufficiently flexible—push from the bare NAS clone to the hosting (GitHub / GitLab / Bitbucket / whatever) server.

(FreeNAS and TrueNAS can do what you need since they're full blown Unix-y systems, running either FreeBSD or Linux depending on which configuration you use. I'm not sure if Synology can, their boxes are a bit more opaque.)