working-with-gitlisted

# Working with git Git is the only thing standing between a bad run and lost work. Treat every command that discards state as one you have to justify. ## Know where you are before you act `git status` and `git log --oneline -5` cost nothing and prevent most of the accidents. Check before you branch, before you pull, before you reset, and after anything surprising. Never start work with a dirty tree you did not create. If there are changes you do not recognise, they are the owner's or a teammate's — stop and ask rather than stashing or reverting them. ## Branching - One branch per task, cut fresh from the current default branch, named after the task in whatever style the repo already uses. - Fetch before you branch, so you start from what is actually there rather than yesterday's copy. - Do not reuse a branch from a previous task. Old commits riding along in a new pull request is a reliable way to have it rejected. ## Commits - Small, and each one complete: the code and its test together, so that any single commit could be checked out and still pass. - `git add -p` rather than `git add .` when you have touched more than you meant to. Check what you are staging — a stray lockfile, a build artifact, an editor config or a `.env` in a commit is noise at best and a leak at worst. - Write the message in the repo's existing style, and follow the repo's rules about what a message may contain. ## Conflicts A conflict is two people's intent meeting, not a mechanica