Main is where finished work lands. Not where it happens.

Git stores your project as a graph. Every commit is a full snapshot plus a pointer to its parent. A branch is nothing but a movable label pointing at one commit.

main is a label. feature/login is a label. Creating a branch copies nothing and costs nothing — which is why teams branch constantly, even for twenty-minute experiments.

Three consequences unlock everything else on this page. Branching is free, so isolation is free. Merging is graph surgery — git combines two lines of history automatically wherever the changes don't overlap. And HEAD is just where you're standing; switching branches loses nothing, because commits stay in the graph. But checking out a raw commit hash instead of a branch name — from git log output, a CI link, or git checkout <hash> — detaches HEAD from any branch; commits made there are still real, but if you don't give them a branch (git switch -c newbranch or git checkout -b newbranch) before switching away, they become exactly the kind of "lost" commit git reflog exists to recover.

If you've ever been afraid of losing work: committed work is almost impossible to lose. git reflog records where HEAD has been — ninety days for entries still reachable, but only thirty days once they become unreachable (e.g. after a reset or amend), and it's that thirty-day window that matters for recovering a "lost" commit. The genuinely dangerous commands are the ones that touch uncommitted work (reset --hard, checkout -- file) — Git 2.23+ split checkout into git switch (change branches) and git restore (discard/restore file changes) to remove that ambiguity; this doc uses checkout throughout, but switch/restore are the newer, less error-prone equivalents. Commit early and often, and git becomes very forgiving.

Merge commit keeps the branch's full history — honest but noisy; every "wip" and "typo" commit lands in main's log.

Squash and merge compresses the whole branch into a single clean commit: "Add password reset (#214)". The most common default, and a good one to reach for unless you have a specific reason to want per-commit history on main — your messy 14 commits stay on the branch, main gets one tidy one.

Rebase and merge replays your commits on top of main for a perfectly linear history. Elegant — but rebase rewrites commit hashes, hence the iron rule:

Keeping a long branch current

git merge main    # pull main into your branch; adds a merge commit
git rebase main   # replay your commits on new main; linear

Either is fine on a branch only you touch. The point is to sync regularly so the final merge is small and boring instead of a week of divergence colliding at once.

CI runs your project's checks on every push and every PR — on a fresh machine, from exactly what's committed.

The configuration is a file in the repo itself. For GitHub Actions it lives in .github/workflows/:

name: ci
on:
  pull_request:
  push: { branches: [main] }
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: docker compose -f compose.yaml \
             -f compose.ci.yaml up --exit-code-from tests

Read it top to bottom: when (PRs and pushes to main), spin up a clean Linux box, check out the code, install, lint, test — then run the whole compose stack and test the pieces together. tests is a service defined in compose.ci.yaml (section 8) — its exit code decides whether this step passes.

The fresh-machine detail matters more than it looks. CI proves the project builds from scratch from what's committed. A file you forgot to add, a tool only your laptop has — CI catches it on day one, not during an emergency.

Combined with branch protection — "merging requires green checks" — CI makes one whole class of accident structurally impossible: merging code you never tested. The robot never gets tired and never skims a diff.

Same PR machinery, different trust question: do you have write access?

Branch — you're on the team, you have write access. Push branches straight to the shared repo, open PRs from branch → main inside it. This is your daily mode.

Fork — you don't have write access. Copy the whole repo to your own account, branch there, then open a PR from your fork back to the original. This is how a stranger can propose a fix to any open-source project without anyone handing over keys. Maintainers review it exactly like a teammate's PR.

On a fork you keep two remotes — origin (your copy) and upstream (the original) — and periodically sync:

git remote add upstream https://github.com/them/project.git
git fetch upstream
git merge upstream/main

When this matters to you: the day you hit a bug in an open-source library you use. Fork, branch, fix, PR to the maintainer.

Drag the slider. These are the three workflow families you'll meet in the wild; the diagram redraws the shape of history each one produces.

Keep

• Branch for anything non-trivial. Thirty seconds buys you: main always works, experiments are free, half-finished work never blocks an urgent fix. The moment you think "I'll just be careful" — branch.
• PRs to yourself. No reviewer needed. You still get CI-before-merge, a self-review pass of the diff (reading a diff catches bugs that writing the code never does), and a searchable answer to "why did I change this?" six months out.
• Branch protection on main. Require PRs and green checks — GitHub lets you require checks without requiring reviews. Now you cannot push broken code to main from either machine, even at 1 a.m. The single highest-value team practice for a solo dev.

Drop

• Approval requirements, develop branches, release branches — GitHub Flow, solo edition.
• Long-lived branches. You're your only integrator; merge within a day or two.

Change — the multi-machine ritual

The rejected pushes you've hit come from two machines each believing they're the source of truth. The fix is a ritual, not a tool: origin is the source of truth; machines are disposable caches.

• Arriving at any machine: git fetch origin, then git status — see where this machine stands before touching anything.
• Leaving any machine: commit — even "wip: half-done form validation" — and push the branch. An unpushed commit exists on exactly one hard drive.
• Pushing a wip commit to your own feature branch is always safe: nothing depends on it, and squash-merge erases the mess later. That freedom is precisely what committing straight to main never gave you.