git-workflow

Safe Git Branch Workflow

Use when managing feature branches and keeping history clean without losing work. The whole point of the discipline is that every destructive command is recoverable and no shared branch is ever rewritten out from under a teammate.

Branch + commit flow

git switch -c feat/thing        # branch off main, off a fresh main
git add -A
git commit -m "feat: add thing"

Convention this house follows (and Skill Vault's own commit log uses): commit messages in imperative mood (add, fix, seed: ...), type: subject format, no trailing &, and no unbalanced quotes — because a tool parses your output. Keep the subject under ~72 chars; put detail in the body.

Rebase onto latest main (preferred over merge)

git fetch origin
git rebase origin/main
# resolve conflicts, re-add resolved files, then:
git rebase --continue
git push --force-with-lease

What rebase actually does to the graph

Before (your branch feat forked from an old main):

      A---B---C   feat
     /
D---E---F         main

After git rebase origin/main:

              A'--B'--C'   feat
             /
D---E---F---G              main   <- G is origin/main's newest

Your commits are A B C re-played as new commits A' B' C' on top of the current main tip G. They keep the same content/message but get new SHAs. Merging instead produces a visible M merge commit and keeps the fork point — fine for shared branches, noise for solo work. Prefer rebase for a linear, readable history on a branch only you own.

--force-with-lease vs --force

• git push --force — overwrites the remote ref unconditionally. On a shared branch this permanently deletes whatever a teammate pushed since your last fetch. There is no remote-side undo.
• git push --force-with-lease — only overwrites if the remote tip still matches what you last fetched. If someone pushed in between, it refuses and tells you to fetch again first.