Common Git Commands | DevOps Peach

Create and switch branches with git switch -c (or checkout -b), push new branches with push -u, update with pull --rebase, view history with log --oneline --graph, park work with stash and mark releases with tags.

Group	Commands	Notes
Start	`git init -b main`, `git clone URL`, `git remote add origin URL`	`clone` only the first time
Record	`git add`, `git commit -m`, `git diff`, `git log --oneline --graph`
Branch	`git branch` (list), `git switch -c feature/login`	Old way `git checkout -b`; `git checkout BRANCH` only switches, it does not create
Sync	`git push -u origin feature/login`, `git pull --rebase`	`-u` = `--set-upstream`; afterwards a plain `git push`
Combine	`git merge feature/login`, `git rebase main`	Do not rebase shared branches
Other	`git stash` / `git stash pop`, `git tag v1.0.0`, `git push origin v1.0.0`	Tags are not pushed automatically

gitGraph
  commit id: "init"
  commit id: "readme"
  branch feature/login
  checkout feature/login
  commit id: "login form"
  commit id: "validation"
  checkout main
  commit id: "hotfix"
  merge feature/login
  commit id: "v1.0.0" tag: "v1.0.0"

pull = fetch + merge; --rebase replays your local commits on top of the remote's new commits for a straighter history.
The first git push of a new branch needs -u origin NAME to create the remote branch and record the upstream.
git stash parks uncommitted changes so you can switch branches; git stash pop brings them back.
Never git push --force to main — it overwrites others' history; if truly needed on your own branch, use --force-with-lease.

Traps: mixing up pull (fetch down) and push (send up); running git pull origin master when the default branch is already main.

Command	Meaning
`git switch -c feature/login`	Create and switch to a branch
`git push -u origin feature/login`	Push a new branch, set upstream
`git pull --rebase`	Update with a straight history

Undoing things safely

Situation	Command	Effect
Fix the last commit message or add a forgotten file	`git commit --amend`	Rewrites the last commit; only before pushing
Undo a pushed commit	`git revert <sha>`	New commit that reverses it; history stays intact
Move a branch back, keep changes staged	`git reset --soft HEAD~1`	Uncommits, files stay staged
Throw away local commits and changes	`git reset --hard origin/main`	Destructive; check `git status` first
Recover a "lost" commit	`git reflog` then `git switch -c rescue <sha>`	The reflog remembers where HEAD has been

Rule of thumb: on shared branches use revert; rewrite history (amend, reset, rebase) only on commits nobody else has pulled.

Resolving a merge conflict

git merge feature/login (or a rebase) stops with CONFLICT and lists the files.
Open each file; Git marks the two versions between <<<<<<<, =======, and >>>>>>>.
Edit to the correct final content and delete the markers.
git add the files, then git commit (or git rebase --continue).

git merge --abort or git rebase --abort returns to the state before you started.

Useful everyday tools

.gitignore lists files Git should never track: build output, node_modules, .env files with secrets.
git log --oneline --graph --all draws all branches; git log -p path/file shows a file's history with diffs.
git blame file shows who last changed each line, useful for finding context, not for blame.
git cherry-pick <sha> copies one commit onto the current branch, for example a hotfix onto a release branch.
git config --global user.name "Your Name" and user.email set the author recorded in every commit; set them once on a new machine.

Writing good commits

Keep each commit focused on one change, write a short imperative subject ("Add login form validation"), and explain why in the body when it is not obvious. Many teams follow Conventional Commits (feat:, fix:, docs:), which tools use to generate changelogs and version numbers.