Configure and inspect

Before committing on a new machine, confirm each configuration layer and avoid stale credentials:

git config --system --list
git config --global --list
git config --local --list
git config --list --show-origin

Set identity and useful aliases:

git config --global user.name "Team Member"
git config --global user.email "[email protected]"
git config --global core.editor "code --wait"
git config --global alias.st status

Share ignore rules across repositories:

git config --global core.excludesfile ~/.gitignore_global
echo '.DS_Store' >> ~/.gitignore_global

Path from working tree to commit

Know how changes move between working tree, index, and repository:

git status -sb
git add <file>
git add .
git restore --staged <file>
git restore <file>

Keep each commit focused:

git commit -m "feat: add weekly report export"
git commit --amend --no-edit

Split work with interactive staging:

git add -p
git commit --amend

Commit conventions

Use the Conventional Commits format so tooling and teammates can quickly understand intent:

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Common type values:

  • feat: add a feature
  • fix: correct a bug
  • docs: documentation changes
  • style: non-functional formatting tweaks
  • refactor: structural changes without feature impact
  • test: add or adjust tests
  • chore: build scripts or auxiliary tasks
  • perf: performance improvements
  • ci: continuous integration configuration

<scope> names the module touched, such as ui or api. The description summarises the change, the optional body explains context, and the footer carries metadata like issue references.

Examples:

feat(auth): add JWT authentication support
fix(api): correct GET parameter handling
docs(readme): refresh installation instructions
refactor(core): restructure the data processing flow
test(ui): add coverage for the button component

History toolbox

Visualise divergence and recent work:

git log --oneline --graph --decorate --all

Drill down into details:

git show <commit>
git diff HEAD~1 HEAD
git blame <file>

Recover from mistakes:

git reflog
git reset --hard <ref>
git cherry-pick <commit>

Branch management basics

Common branch operations:

git branch
git branch -r
git switch <branch>
git switch -c feature/login

Stay current before merging:

git fetch origin
git merge origin/develop

Resolve conflicts and finish the merge:

git status
# edit conflict markers <<<<<<< ======= >>>>>>>
git add <resolved-file>
git commit

Sync with remotes

Rebase pulls keep history linear:

git pull --rebase origin develop

Push while setting upstream tracking:

git push -u origin feature/login

Prune stale remote branches:

git fetch -p

Rename or delete remotes:

git branch -m old-name new-name
git push origin :old-name
git push -u origin new-name

Tags and releases

Create annotated tags for releases:

git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0

Delete tags locally and remotely:

git tag -d v1.1.0
git push origin :refs/tags/v1.1.0

Stashing work in progress

Store unfinished changes before context switching:

git stash push -m "wip: dashboard chart"
git stash list

Restore and drop:

git stash pop stash@{0}

Apply while keeping the entry:

git stash apply stash@{0}
git stash drop stash@{0}

Quick checklist

  • Is git status clean?
  • Have the latest commits from origin/<branch> been fetched?
  • Are all conflicts resolved and restaged?
  • Do the last few commits (git log --oneline -5) follow the naming convention?
  • Are branch names and tags correct before pushing?

.gitignore essentials

A .gitignore keeps generated files out of the repository. Typical patterns look like:

*.txt          # ignore every txt file
!666.txt       # but keep this specific file
test/          # ignore entire directory
xxx/*.txt      # current directory only
xxx/**/*.txt   # include subdirectories

When cloning, Git creates a default remote alias named origin. It is only an identifier pointing to the remote URL—not a branch—and tells Git where to fetch and push. Add additional aliases such as upstream or backup only when needed.

This article covers the essentials. See “Git Collaboration Cheat Sheet (2) Advanced Techniques” for rebase workflows, bisect strategies, worktrees, and multi-remote setups.