Git and GitHub Cheat Sheet
A Git and GitHub reference for worktrees, staging, commits, branches, merges, remote sync and conflict review.
What this reference covers
This Git and GitHub reference follows a daily collaboration path from worktree and staging area to commits, branches, remotes, merges and conflict review. It is useful when a command is forgotten or a content and code batch needs a repeatable handoff.
Know the state before changing it
Start by checking the current branch, worktree changes, staged diff and remote relationship. A commit is a snapshot in local history, while a push shares commits with a remote repository. These boundaries make it easier to choose what belongs in the next change.
Keep changes small and reviewable
Stage only files belonging to one logical change, inspect the diff and check for secrets, environment files, build output and large binaries. Use a branch for a feature, fix or content batch, then run validation before merging or opening a review.
Maintenance note
Conflict resolution requires checking both intent and behavior. Version control records history but does not replace access control, code review, backups or credential rotation. Content review date: 2026-08-23.
Save to your cloud drive
Save the complete collection first so files remain together and are easier to access across devices.
Quark Cloud Drive
RecommendedSave Git and GitHub Cheat Sheet to this cloud drive
Baidu Netdisk
Save Git and GitHub Cheat Sheet to this cloud drive
Git and GitHub study guide
Check repository state first, make small commits on an isolated branch, synchronize deliberately and verify the result after conflicts.
Before you start
- Prepare a PDF reader and a practice repository with a remote branch.
- Understand worktree, staging area, commit, branch, remote and code review concepts.
- Use a practice branch for experiments instead of changing an important shared branch directly.
Quick start
- 01
Check current state
Inspect the branch, worktree changes, staged files and remote position before editing or pulling new history.
- 02
Make a focused commit
Stage only the files for one logical change, review the diff and sensitive-file list, then write a message that describes the result.
- 03
Isolate work in a branch
Create a branch for a feature, fix or content batch, complete local checks and keep the branch ready for review or merge.
- 04
Synchronize and resolve
Update from the remote before merging, resolve conflicts section by section, review the full diff and run tests or a build afterward.
Usage tips
- Check secrets, environment files, build artifacts and oversized files before every commit.
- Write commit messages that state what changed and add the reason or verification when the batch is complex.
- Confirm team rules before rewriting history on a shared branch.
Troubleshooting and uninstall
Why did tests fail after a merge?
Inspect the conflict resolution and complete diff for deleted or duplicated behavior, then trace the failure to the relevant commit and rerun validation.
Why was a remote push rejected?
Confirm the current branch, remote address and permissions, then synchronize the latest history instead of force-overwriting a shared branch.
Frequently asked questions
How do worktree, staging area and commit differ?
The worktree contains current file changes, staging selects the next snapshot and a commit records that snapshot in local history.
Why use small commits?
Small commits are easier to review, revert and diagnose, and keep separate features or content batches independent.
What should happen after resolving a conflict?
Review the full diff, confirm both sides intent is preserved and run the relevant tests or build before completing the merge.
How does a remote repository relate to local Git history?
Git keeps local history and a remote shares or backs it up; push, pull and merge synchronize commits but do not judge business correctness automatically.