All topics
The network drive
Files and websites
Cameras and sensors
Network and questions
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:
- Private or Protected: cloning, fetching and pushing all require an account.
- Public read: anyone can clone and fetch; pushing always requires an account.
- Off: the repository is not served at all.
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.