Git, GitHub & backups

You just laid down an agent that’s going to write code at full speed. Before it touches anything important, we install the safety net: Git, so every change is reversible, and GitHub, so your work lives somewhere other than this one little box. Because a mini-PC can fry, get stolen, or take one rm too many. Your code, though, must never disappear with it.

Why this is non-negotiable (especially with an agent)

A coding agent moves fast, and it’s confident in itself. Most of the time that’s great; sometimes it breaks something. Git turns that into a non-event:

• Every commit is a restore point. The agent broke everything? git restore or git reset, and you’re back to the previous state in a second. It’s the ultimate “undo.”
• You see exactly what changed. git diff shows you, line by line, what the agent touched. You review before approving, that’s the heart of the craft (see Securing access).
• GitHub puts your code out of reach of disasters. Dead disk, theft, fat-fingered mistake: your code is on GitHub, intact. You get it back on any machine with one command.
• And you can share. Granting access to a colleague, working as a team, going open source: it all goes through GitHub.

Configure Git on the machine

Three lines, once and for all. Git needs to know who you are (it signs your commits):

git config --global user.name "Your First Last"
git config --global user.email "[email protected]"
# A few sane defaults
git config --global init.defaultBranch main   # the default branch is called "main"
git config --global pull.rebase false          # predictable pull behavior

Give the machine access to GitHub

Your machine has to prove to GitHub that it’s allowed to push. Two paths; take the one that speaks to you.

Your first repo, and the agent that uses it

cd ~/my-project
git init
# The file that tells git what to IGNORE, crucial
cat > .gitignore <<'EOF'
node_modules/
.env
*.log
dist/
EOF
git add -A
git commit -m "First draft"
# Create the remote repo and push (with gh, it's one line)
gh repo create my-project --private --source=. --push

Once it’s in place, ask your agent to handle git for you: “regular commits with clear messages,” “create a branch for this feature,” “open a pull request.” You can even write it into your memory file: “commit after each approved step, conventional messages, only push to main with my OK.”

Backups: the 3-2-1 rule

GitHub saves your code. But your mini-PC contains plenty of other things that aren’t in git: your .env files, your databases, generated data, system configs. For those, we apply the golden rule of backup:

Three traps you only discover when restoring

Target the disk by its label, never by its path

An external disk does not always mount in the same place. If the folder already exists, your desktop appends a digit and mounts on /media/you/1TB1, leaving /media/you/1TB behind as an empty folder on the system disk.

The naive test [ -d "$DEST" ] passes just fine. And your backup quietly writes to the system disk while believing it is writing to the external one.

# resolve by label, and demand a real mount point
DEST="$(findmnt -rn -S LABEL=1TB -o TARGET 2>/dev/null | head -1)"
[ -n "$DEST" ] && mountpoint -q "$DEST" \
  || { echo "external SSD not mounted, backup cancelled"; exit 1; }

A hardcoded list forgets the newcomers

A script that lists your databases by hand never backs up the project you created last month. And it does not say so. Sweep what is actually running:

for c in $(docker ps --format '{{.Names}}'); do
  # probe for the tool rather than matching the image name:
  # this also catches pgvector, timescaledb and other derivatives
  docker exec "$c" sh -c 'command -v pg_dumpall' >/dev/null 2>&1 || continue
  docker exec "$c" pg_dumpall -U postgres | gzip > "$DEST/$c.sql.gz"
done

A destructive rebuild must be atomic

A script that deletes the database then rebuilds it leaves you with nothing if it dies halfway. Build alongside, then rename: on the same filesystem, renaming is atomic.

sqlite3 base.sqlite.tmp < schema.sql
# … filling …
mv base.sqlite.tmp base.sqlite      # instant swap, or nothing

And before the swap, check: integrity, index count, row floor. A rebuild that half succeeds otherwise passes for a success.