how i use git

2023/06/20 by huck boles

i host all of my repositories myself. mainly because i want to be in complete control of my code.

my central repository lives on an nfs drive on one of my servers. this is not itself a git repo, but contains bare repos for every one of my projects. these are the source repositories that everything else pulls from and pushes to.

i can clone a repository onto a local computer straight from the file system if it is connected to the nfs drive, or through ssh if i need remote access. this lets me easily keep projects and configurations in sync across my various installs.

for my public repositories i maintain separate pull-only repositories on my web server. these are synced with the source repos hourly and served over http or git protocol. this provides a layer of protection from accidental or malicious edits from the web portal.

i use gitweb as a web portal, as it’s easy to maintain and comes with git. i actually really like the bare-bones nature of it, as it makes it relatively simple to edit the css to fit in with my website. it provides all i need, a file tree, commit history, logs, and gives a method for cloning my public repositories.

i mirror my repositories to github in a similar manner as gitweb, but only sync them nightly. i mainly do this for the ability to maintain github specific readmes or other things i occasionally need. it also keeps my main repository free of extraneous remote branches and sync issues.

all of my syncing is done with various shell scripts triggered by cron jobs. my computers all have a script that runs nightly to push commits to the main repository if they can merge cleanly. i also have a script that compresses and encrypts the entire central repository, which then syncs with a backup drive for recovery purposes.

for complicated projects, i use git worktrees, which gives you a separate directory for each branch. i really enjoy using this because it lets you switch contexts just by changing directories.

this fits in very nicely with my development method, as i usually have a main branch for releases, a devel branch for general unreleased improvements, and small feature branches that split off of devel that i use for adding new features without polluting the main codebase.

it’s not a very radical workflow, but it suits my mainly solo dev workflow. with all of my repositories in my local network, it’s extremely fast, and everything stays in sync super well without much fuss.