How I Use Git in a Real Team Environment

The command cheatsheet is the daily commands. This post is how those commands behave when other people are on the same repo.

One branch, one outcome

A branch name states the outcome, not the file you touched. fix/cart-string-quantity is reviewable. safdar-updates is not. I open the pull request before the branch is perfect, with a short description of what a reviewer should try.

Commits a reviewer can revert

fix: parse cart quantity before adding price

Form values arrive as strings. "2" + 499 became "2499".

The subject says why the change exists. The body says the failure that made it necessary. I do not mix a formatter pass and a behaviour change in the same commit. Reverts get messy, and git bisect stops being useful.

Review

I pull the branch and run the app when the change touches rendering or data. Comment on behaviour, not taste, unless the repo already has a written rule. "Can we use === here because both sides should already be numbers?" is a useful comment. Rewriting someone's variable names in review is not, unless the name lies.

Main stays deployable. Feature flags beat long-lived branches. If a branch is older than a few days, I rebase or merge main into it on purpose, then retest the conflict, instead of hoping the diff still means what it meant on Monday.

What I will not do to the history

I do not rewrite published history to make a contribution graph look busy, and I do not force-push a shared branch after review has started unless the team agreed and the old commits are unsafe to keep. Dates on commits are when the work landed. Future you, and the person bisecting a production bug, need that to be true.