How I use GitHub

I use GitHub for the obvious things: storing code, tracking changes and collaborating. When I first learnt to code, I kept running into the same problems:

How could I make changes to a codebase without losing the original version?
How could I work on the same project across multiple devices?
How could I deploy the code and integrate it with other tools?

Great tools are often discovered through frustration. GitHub solved those problems, and now I start almost every project with it.

zsh

mkdir new-project
cd new-project
git init
git add .
git commit -m "initial commit"

Once Git is initialised, the project isn’t just a folder on my Mac. It can be viewed, reviewed, worked on, deployed and picked up again later.

I can start locally, continue on another device, collaborate with someone else, or give agents like Hermes or Codex access to the repo. Everyone works from the same project, and every change leaves a trail.

Automations in the background

A lot of my projects have small workflows running in the background: checks, deployments, audits, updates, and experiments that should happen without me needing to remember every step manually.

Depending on the project, that might include Prettier, linting, type checking, Python checks, Playwright tests, Lighthouse audits or deployment workflows.

Sanity github actions workflow — Specific changes trigger specific deploys

typecheck github actions — Lint, test, build, then continue

None of these workflows are particularly exciting, but they remove the small checks I would otherwise forget and give me more confidence when I merge or deploy.

Agents

Repos are no longer only shared between people. They are workspaces for agents too.

Every project I work on has some LLM involvement; I mainly code in Cursor, and use Hermes or Codex for internal tooling/PRs. With access to the repo, they can inspect the project’s structure, trace how functions connect across files, read the files and understand the patterns in the codebase.

An agent can take an issue, create a branch or worktree and work independently without interrupting me. It can search and edit files, add tests, run checks, investigate failures, commit the work and open a pull request.

Workflow steps: issue/task, agent reads repo, creates branch/worktree, changes code, runs tests, opens pull request, review/merge.

Worktrees are especially useful because each agent can have its own isolated copy of the repo. I can continue working in mine while (often) several agents work on separate tasks without overwriting one another or working in the same branch.

Once a PR is made, I can inspect exactly what changed, question a decision, request another approach or ask the agent to fix something before it is merged.

Agents can also work around the code: reviewing pull requests, investigating failed workflows, updating documentation, triaging issues, finding duplicated logic and identifying which files may be affected by a change.

GitHub sits underneath nearly everything I build. Each project starts there, then becomes a shared space between my local code, collaborators, agents, automated checks and whatever eventually runs in production.