Git Workflow

Git Workflow

Overview

This skill provides a disciplined, safe workflow for everyday Git: branching, crafting clean atomic commits, rewriting history with interactive rebase, resolving conflicts, and recovering from mistakes using the reflog. The guiding principle is safety first — never destroy work you cannot recover, always know your escape hatch before running a history-rewriting command.

Keywords: git, branch, commit, rebase, interactive rebase, squash, fixup, reword, cherry-pick, merge, conflict, conflict resolution, reflog, recover lost commits, undo, reset, revert, detached HEAD, force-push, stash, clean history, conventional commits, PR prep.

Golden rules

1. Never rewrite history that others have already pulled (shared branches like main/develop). Rewrite only your own unmerged feature branches.
2. Before any rebase, reset --hard, or force-push, note the current commit: git rev-parse HEAD or just trust the reflog — it remembers.
3. Prefer git push --force-with-lease over --force. It refuses to clobber commits you haven't seen.
4. Commit early, commit often locally; clean up into atomic commits before sharing.
5. If something looks lost, it almost certainly isn't — go to git reflog (see references/reflog-recovery.md).

Workflow

1. Orient before acting

Always understand current state first:

git status            # working tree + branch
git log --oneline -10 # recent history
git branch -vv        # branches + tracking

2. Branch

• Update the base first: git switch main && git pull --ff-only.
• Create the branch: git switch -c feat/short-description.
• Naming: <type>/<slug> e.g. feat/oauth-login, fix/null-deref, chore/bump-deps, docs/readme. See references/branch-naming.md.

3. Make atomic commits

• One logical change per commit. Stage selectively: git add -p to split a working tree into focused hunks.
• Write a Conventional Commit message (see references/conventional-commits.md):

  feat(auth): add OAuth2 PKCE login flow
  
  Body explaining WHY, wrapped at ~72 cols. Reference issues.
  

• Verify before committing: re-read git diff --staged.

4. Keep up to date with the base

Choose merge vs rebase intentionally (see decision framework below). For a private feature branch, rebasing keeps history linear:

git fetch origin
git rebase origin/main

5. Clean up history before opening a PR

Squash noise ("wip", "fix typo"), reword unclear messages, reorder for logical flow:

git rebase -i origin/main

Full guidance and the command cheat sheet: references/interactive-rebase.md. Validate the result before pushing: scripts/rebase-safety-check.sh.

6. Resolve conflicts methodically

When a rebase/merge stops on a conflict, follow the step-by-step protocol in references/conflict-resolution.md. Summary:

git status                 # see conflicted files
# edit files, remove <<<<<<< ======= >>>>>>> markers
git add <resolved-files>
git rebase --continue      # or: git merge --continue
# abort anytime: git rebase --abort / git merge --abort

7. Share

git push -u origin feat/short-description           # first push
git push --force-with-lease                         # after a rebase/amend

8. Recover when things go wrong

Nothing is lost until garbage collection runs (default ~30–90 days). See references/reflog-recovery.md and run scripts/git-recover.sh to surface candidate lost commits.

Decision Framework: Merge vs Rebase

Rule of thumb: rebase local, merge shared.

Interactive Rebase Quick Reference

In the git rebase -i todo list, set the action keyword on each line:

Targeted fixup workflow (best for PR review fixes):

git commit --fixup=<sha>          # creates "fixup! ..." commit
git rebase -i --autosquash origin/main   # auto-positions & marks it fixup

Recovery Cheat Sheet

Best Practices

• Make the first line of a commit ≤ 50 chars, imperative mood ("add", not "added").
• Run scripts/rebase-safety-check.sh after a rebase to confirm no commits were silently dropped and the tree still matches expectations.
• Use git add -p to keep commits atomic instead of git add ..
• Prefer git switch/git restore over the overloaded git checkout.
• Tag the pre-rebase state if nervous: git tag backup-before-rebase. Delete it when done.
• Configure git config rerere.enabled true to let Git remember conflict resolutions across repeated rebases.

Common Pitfalls

• Force-pushing a shared branch and erasing teammates' commits. Use --force-with-lease, and never on main.
• Rebasing main/develop — rewriting public history breaks everyone. Use revert instead.
• git reset --hard without checking — you lose uncommitted working-tree changes permanently (these are NOT in the reflog). Stash first.
• Resolving a conflict by deleting the wrong side — read both sides; the markers are <<<<<<< HEAD (current/your side during merge) vs >>>>>>> branch (incoming). During rebase the sides are swapped — see references/conflict-resolution.md.
• Committing generated files / secrets — review git diff --staged; use .gitignore.
• Assuming work is gone after a botched rebase — check git reflog before doing anything else.

Bundled Files

• references/interactive-rebase.md — complete interactive rebase guide with worked scenarios.
• references/conflict-resolution.md — step-by-step conflict protocol, marker semantics, rerere, tools.
• references/reflog-recovery.md — recover lost commits, branches, resets, detached HEAD, wrong-branch commits.
• references/conventional-commits.md — message format, types, scopes, breaking changes, examples.
• references/branch-naming.md — naming conventions and branching models.
• scripts/git-recover.sh — list recently dangling/unreachable commits with previews to aid recovery.
• scripts/rebase-safety-check.sh — sanity-check history after a rebase against the upstream base.
• examples/squash-feature-branch.md — end-to-end worked example of cleaning a messy branch.