All topics

Git Repositories

The device can host git repositories: clone, fetch and push over HTTP with any git client, and publish a website with every push. Your code lives on your own hardware.

Creating a repository

On the Content tab, choose New Git Repository… and it appears in the tree as a folder of its own name, with a .git directory inside it. A repository is an ordinary checkout, not a bare one, so the files themselves are right there: browse them in the Files app, open them on the network drive, or read them with an S3 client like any other folder. The repository's detail screen shows the clone URL and the branch that is checked out, and lets you switch to another one.

Cloning and pushing

Repositories use device accounts, the same username and password as the network drive. The repository's access level decides who needs one:

Over HTTPS, clients sign in with the ordinary password prompt. An account's API tokens work in place of the password, so scripts and build machines can hold a revocable credential of their own. Even plain-HTTP connections on the local network never send the password itself: the server uses digest authentication there. An account can also be scoped to particular repositories; the ones it cannot reach answer as though they were not there.

Pushing updates the files

Because a repository is a checkout, pushing to the branch it has checked out also updates the working tree, the way git's own updateInstead does. Push a commit from your laptop and the new files are immediately what the Finder, the Files app and any website served from that folder see, with no deploy step in between.

The tree is only moved when it is safe to move: a push is refused if the checkout has tracked changes of its own, staged or unstaged, and the client is told why in the usual [remote rejected] line. Untracked files never get in the way. Pushing to any other branch is an ordinary push and leaves the working tree alone.

Large files

The server speaks Git LFS, so repositories with large binaries work without a second service to run. Pushes and clones carry LFS objects through the standard batch API, and the objects are stored beside the repository in .git/lfs/objects in git-lfs's own layout. The git lfs command line and Working Copy both work against it unchanged, and switching branches in the app fetches whatever objects the new branch needs.

Working Copy and other clients

Working Copy, from the same developer, discovers NAS Reborn servers on your network automatically and offers them as a hosting provider, so cloning from and pushing to the device needs no URL typing at all. Any other git client works with the clone URL, and the server also answers a slice of the Gitea API, so tools that list and create repositories on a Gitea server can do the same here.

Push to publish

A repository that contains a website, whether plain HTML or a Jekyll-style template site, is also served as one: it is published at https://yourserver.nas2.dk/name/ under the repository's name, subject to the same public-read access level as any site. Because a push moves the working tree in one step, visitors always see a complete revision, never a half-updated one. Write a post in Working Copy on the sofa, push, and the site is live on the device.

Free tier

The free tier serves up to 2 repositories. Repositories have their own budget: hosting one does not spend from the folder limit, even though a repository is a folder in every other sense. With more than 2 turned on, git serving pauses until a repository is set to Off or deleted, and the Pro unlock removes the limit. As with everything else, the repositories themselves stay plain folders in the Files app.