Git commands grouped by the job you need done, in plain words, with the risky ones clearly marked.
You don't need the terminal for our Git course. This page is for the moments it shows up anyway: an engineer's instruction, a local copy of the repository, a pull request you want to run.
New to Git as a PM? Git for product managers: read the repository, skip the command line
Words in angle brackets are placeholders. Replace <branch>, <file>, <commit> or <text> with your own value and drop the brackets. A <commit> is a hash such as 3f9a2c1; a <tag> is a version such as v1.5.0.
Every command carries one of three labels:
Written for Git 2.23 or newer (git switch and git restore need it). Check yours with git --version.
63 commands
Get the project onto your laptop and find your way around it before you touch anything.
git clone <url>Download a full copy of a repository, history included.
Creates a new folder with every file and every commit of the project. Nothing on GitHub changes, and nothing already on your laptop is touched. You only need it when you want to run or search the project locally.
To read the project you don't need a copy: browse the repository page. The address for git clone is under the green Code button.
git statusSee which branch you are on and which files you have changed.
The first command to run when you are unsure. It names your branch, lists edited, new and conflicting files, and says whether you are ahead of or behind GitHub (as of your last fetch). It often suggests the next command too.
git log --oneline --graph --allDraw every branch and merge as a text picture.
One commit per line, with lines on the left showing where branches split off and where they were merged back. Handy for seeing how busy a repository is before you ask where a change went. Press q to leave the list.
Insights → Network draws the same picture for the repository's branches.
git grep "<text>"Find every file that contains a word or a phrase.
Searches the files of your current branch and prints each matching line with its file name. Useful to find where a button label, a price or a feature flag lives. It only searches today's files, not deleted text.
Use the search field at the top of the repository page (press /) and keep the results to this repository.
git config --global user.name "<name>"Set the name that appears on your commits.
A one-time setup on a new laptop. Git writes this name into every commit you make from now on, in every repository on this computer.
Commits you already made keep the old name; a typo shows up in the shared history until you run the command again with the right spelling.
git config --global user.email "<email>"Set the email that links your commits to your GitHub account.
GitHub matches this address to your account to show your avatar next to your commits. Use the address from your GitHub email settings; GitHub also offers a private noreply address for this.
The address is stored in every commit you make, and anyone who can read the repository can see it.
Recent commits, one commit up close, and what a branch adds compared with main.
git log --oneline -20List the last 20 commits on your branch, one line each.
Each line starts with the short commit hash and the commit message, newest first. It is the quickest answer to "what happened here lately?". Change 20 to any number you like.
On the repository page, click the commit count with the clock icon above the file list.
git log --since="2 weeks ago" --onelineSee every commit from the last two weeks.
Filters the history by date, which is handy before a sprint review or a stakeholder update. Git understands phrases like "3 days ago" or a date like "2026-09-01".
Open the commits list and pick a date range in its date filter.
git show <commit>Open one commit: its message, author, date and diff.
Paste the hash from a Slack message or a pull request and you see exactly what that commit changed, removed lines with a minus and added lines with a plus.
Click any commit hash on GitHub to open its page with the same diff.
git diffSee the edits in your folder that you haven't staged yet.
Shows, line by line, how your files differ from their last saved state. Run it before committing to check you changed only what you meant to. Once a file is staged with git add, its edits move to git diff --staged.
git diff origin/main...<branch>See everything a branch changes compared with main.
The three dots mean "since the branch split off from main", so you see only the branch's own work, just like a pull request's Files changed. Run git fetch first so origin/main is current.
Open the pull request and go to the Files changed tab.
git log --oneline origin/main..<branch>List the commits a branch has that main doesn't.
Two dots mean "in the branch, not yet in main". The number of lines is what GitHub calls "ahead". An empty list means everything on the branch is already in main.
The pull request's Commits tab, or the "ahead" count on the branches page.
Also useful here:git log -p -- <file>git branch -r --contains <commit>
Trace a line or a sentence back to the commit that wrote it; the commit leads to the pull request and the reason.
git log -p -- <file>Read the full history of one file, with each change.
Lists every commit that touched the file, newest first, each with its diff. Good for questions like "how did the pricing copy evolve?". Press q to leave.
Open the file and click History in its top right corner.
git blame <file>See who last changed each line of a file, and in which commit.
Prints the file with the commit, author and date of the last change next to every line. It finds where a line came from, not someone to blame. If the last commit only reformatted the line, look one step further back in the history.
Open the file and switch the view from Code to Blame.
git blame -L <start>,<end> -- <file>Find who changed a few specific lines of a file.
The same as git blame, limited to a range of line numbers, for example -L 10,14. Take the numbers from the file view on GitHub. The commit hash in the first column leads to the pull request.
Open the file in the Blame view and scroll to those line numbers.
git log -S "<text>" --onelineFind the commits that added or removed a piece of text.
Searches the whole history for commits where the text appeared or disappeared. It is the tool for "this sentence used to be on the page, who took it out?", which blame can't answer because the line no longer exists.
Also useful here:git grep "<text>"
List branches, move between them, start a new one and tidy up after a merge.
git branchList the branches on your laptop; a star marks the one you're on.
Only local branches: the ones you created or switched to. Branches that exist only on GitHub are not listed here; git branch -a shows those too.
The branch selector above the file list shows the branches on GitHub.
git branch -aList every branch, including the ones only on GitHub.
GitHub's branches appear as remotes/origin/<name>. The list is as fresh as your last git fetch, so fetch first if you are looking for a branch someone just pushed.
The Branches page (the branch count next to the branch selector) lists them with their last commit.
git switch <branch>Move to another branch; your folder changes to match it.
The files in your folder turn into that branch's version. If the branch exists only on GitHub, Git creates a local copy that follows it. Uncommitted edits come along when they don't clash with the other branch.
If your uncommitted edits clash with the other branch, Git refuses to switch until you commit or stash them; nothing is lost, but the folder looks different after a switch.
Pick the branch in the branch selector above the file list.
git switch -c <branch>Start a new branch from where you are and move to it.
The new branch starts at your current commit, so switch to an up-to-date main first if the work should start from main. Name it the way your team does, for example content/delivery-copy.
It starts from wherever you are: from an old or unrelated branch you carry its commits into your pull request.
Open the branch selector, type a new name and click Create branch … from main.
git branch -d <branch>Delete a local branch that has already been merged.
Tidies your laptop after a pull request is merged. Git refuses if the branch holds commits that are not merged anywhere, which makes this the careful way to delete. The branch on GitHub is not touched.
After a squash merge Git often calls the branch unmerged even though the work is in main, because main holds a new commit, not the branch's own ones. That is when people reach for -D.
After a merge, the pull request page offers Delete branch (and Restore branch if you change your mind).
git branch -D <branch>Delete a local branch even if its work was never merged.
The capital D skips the safety check of -d. Engineers use it for experiments they really want gone.
What can go wrong
Commits that were only on that branch disappear from view. For a few weeks git reflog on this laptop can still find them; after that they are lost.
Safer: git branch -d <branch>
Bring in what others merged while you worked. Merging is the calm option; rewriting history is for people who know why they need it.
git fetch originDownload what's new on GitHub without touching your files.
Updates your laptop's picture of GitHub (origin/main and the other origin/… branches). Your own branches and files stay exactly as they were, so it is always safe to run before you compare or check anything.
Not needed: GitHub always shows its latest state.
git pullBring the latest commits of your branch from GitHub into your folder.
A fetch followed by a merge (or a rebase, if your team set it up that way) of the same branch from GitHub. On a branch only you use, it simply brings you up to date.
Your files change, and if you and someone else edited the same lines, the pull stops with a merge conflict you have to resolve or abort.
No direct equivalent: GitHub always shows the latest version. The closest thing is Update branch on a pull request, which brings main into the pull request's branch.
git merge origin/mainBring the latest main into your branch with a merge commit.
Adds what others merged into main while you worked, without changing any of your existing commits. Run git fetch origin first. Afterwards a normal git push is enough.
It may stop with a merge conflict; git merge --abort takes you back to where you started.
On the pull request, click Update branch in the merge box (the default option merges main in).
git rebase origin/mainReplay your branch's commits on top of the latest main.
Instead of a merge commit you get a straight line: your commits are recreated one by one as if you had started from today's main. Some teams require it for a tidy history.
What can go wrong
Every rebased commit gets a new hash, so the branch no longer matches GitHub and needs a force push; anyone else using the branch has to repair their copy. Conflicts can come up once per commit.
Safer: git merge origin/main
Update branch → Update with rebase on the pull request does the same on GitHub.
git push --force-with-leaseOverwrite your branch on GitHub, but only if nobody pushed to it since you last looked.
Needed after a rebase or an amend of commits that were already pushed. Unlike a plain --force, it refuses when the branch on GitHub has commits your laptop hasn't seen.
What can go wrong
It replaces the branch's history on GitHub: commits that are not in your version are dropped from it, and a background fetch by your editor can defeat the check. Never use it on main or on a branch others work on.
Safer: git merge origin/main
With the GitHub CLI you can list, read, try out and approve pull requests from the terminal.
gh pr listList the open pull requests of the repository.
Shows number, title and branch of each open pull request. Add --author @me for your own or --search "review-requested:@me" for the ones waiting for your review.
The Pull requests tab of the repository.
gh pr view <number> --webOpen a pull request's page in your browser.
A shortcut from the terminal to the page you know. Without --web it prints the title, description, reviewers and checks summary right in the terminal.
The pull request page itself.
gh pr diff <number>Read everything a pull request changes, in the terminal.
Prints the same diff as the Files changed tab. Useful when you want to search the changes with your usual tools; it changes nothing locally.
The pull request's Files changed tab.
gh pr checks <number>See whether a pull request's automated checks passed.
Lists each check (tests, build, preview deploy) with its state: pass, fail or pending. Add --watch to wait until they finish.
The checks list in the merge box at the bottom of the pull request, or the Checks tab.
gh pr checkout <number>Get a pull request's branch on your laptop to try the change yourself.
Downloads the branch and switches your folder to it, so you can run the project and click through the feature. Switch back to main with git switch main when you're done.
Your folder switches to the pull request's branch; commit or stash your own edits first, or Git may refuse to switch.
If the team has preview deployments, the link in the pull request's checks lets you try the change without any of this.
gh pr review <number> --approveApprove a pull request from the terminal.
Submits an approving review under your name. Add -b "<text>" to say what you checked, for example that the copy matches the issue.
Everyone sees the approval, and it can be the one that unblocks the merge; approve only what you actually checked.
In Files changed, click the review button (Submit review, or Review changes in older layouts), choose Approve and submit.
gh pr review <number> --comment -b "<text>"Leave review feedback without approving or blocking.
Posts a review comment on the whole pull request. Use it for questions and notes; comments on specific lines are easier in the browser.
The comment is posted at once and notifies the author and reviewers; it can be edited later but not unsent.
Open the review button in Files changed, write your note, choose Comment and submit.
Find the conflicting files, finish the merge once they are fixed, or step back to where you started.
git diff --name-only --diff-filter=UList only the files that still have conflicts.
U stands for unmerged. Each name on the list still has conflict markers (<<<<<<<, =======, >>>>>>>) to sort out; an empty list means you can finish the merge. git status shows the same files among others.
Resolve conflicts on the pull request opens an editor that lists the conflicting files on the left.
git merge --continueFinish a merge once every conflict is fixed.
After you have edited each conflicting file and run git add on it, this creates the merge commit. Git opens an editor with a ready message; save and close it.
Whatever is in the files now becomes the merge result, so check that no conflict markers or half-kept versions are left.
In the conflict editor, click Mark as resolved for each file, then Commit merge.
git merge --abortCancel a merge that stopped with conflicts and go back to before it.
The emergency exit: your branch looks exactly as it did before the merge started. Useful when you need the author of the other change before deciding.
Conflict fixes you have typed so far are thrown away, and if you had uncommitted edits before starting the merge, Git may not bring them back.
Nothing to cancel: leave the conflict editor without clicking Commit merge and nothing is saved.
git rebase --abortCancel a rebase in progress and restore your branch.
If a rebase stops on a conflict and you would rather merge instead, this puts the branch back exactly as it was before the rebase began.
Conflict fixes made during this rebase are discarded.
Also useful here:git statusgit add <file>
Most undo commands keep a record of what you undid. The few that don't are marked in red: read their note first.
git restore <file>Throw away your uncommitted edits in one file.
The file goes back to its last saved version (the staged one if you ran git add, otherwise the last commit). Other files are not touched.
What can go wrong
The discarded edits are gone for good: they were never committed, so Git keeps no copy.
Safer: git stash push -m "<text>"
git restore --staged <file>Take a file out of the next commit, keeping your edits.
The opposite of git add: the file is no longer staged, but its content in your folder stays exactly as you left it.
Low: only the "include in next commit" mark changes; add the file again if you unstaged the wrong one.
git revert <commit>Undo a commit by adding a new one that reverses it.
The safe way to undo something that is already shared: history keeps both the original and the undo, and nobody's copy breaks. Push the new commit (or open a pull request with it) like any other change.
If later commits changed the same lines, the revert stops with a conflict; and it adds a commit to your current branch, so check which branch you are on.
git revert -m 1 <commit>Undo a whole merged pull request without rewriting main.
For a pull request merged with a merge commit: -m 1 tells Git to keep main's side and remove what the branch brought in. If your team squash-merges, the pull request is a single ordinary commit and plain git revert <commit> does the job.
Git still counts that branch as merged: merging it again later won't bring the undone changes back unless you revert the revert.
On the merged pull request, click Revert: GitHub prepares a new pull request that undoes it.
git reset --soft HEAD~1Undo your last commit but keep its changes ready to commit again.
HEAD~1 means "one commit back". The commit disappears from the branch while its edits stay staged, so you can split them or commit them differently.
It rewrites your branch's history: fine for a commit that was never pushed, but a pushed commit would then need a force push.
git reset --hard <commit>Move your branch back to a commit and throw away everything after it.
Makes your folder look exactly like that commit. Engineers use it to start over on a branch nobody else uses.
What can go wrong
Uncommitted edits are lost for good. Commits after that point disappear from the branch; on a shared branch this rewrites history for everyone.
Safer: git revert <commit>
git stash push -m "<text>"Put your unfinished edits aside without committing them.
Your edits go onto a shelf and the folder returns to the last commit, so you can switch branches or pull. The message helps you recognise the shelf later; git stash pop brings the edits back.
Brand-new files are not stashed unless you add -u, and a stash lives only on this laptop, where it is easy to forget.
git stash popBring back the edits you last put aside.
Applies the most recent stash to your folder and removes it from the list. git stash list shows everything you have put aside.
If the files changed meanwhile, you can get a conflict; the stash is then kept, so nothing is lost.
git reflogFind a commit that seems lost after a reset or a deleted branch.
A diary of every place your branch pointer has been on this laptop, newest first. Find the line from before the accident, copy its hash, and an engineer can bring that state back, for example on a new branch with git switch -c <branch> <commit>.
git clean -n -dPreview which untracked files and folders a clean would delete.
-n is a dry run: it only prints the list. Untracked means Git has never had a copy of them, so read this list before any real clean.
git clean -fdDelete all untracked files and folders.
Removes everything Git doesn't know about (new files you never added), leaving ignored files alone. Engineers use it to get a clean folder after a messy experiment.
What can go wrong
Deleted files were never committed, so they are gone for good: not in Git and not in the trash.
Safer: git clean -n -d
Merged is not released. Tags tell you which version first included a change and what went into each release.
git tag --list "v1.*"List the release tags, filtered by a pattern.
* matches anything, so "v1.*" lists every 1.x release. Without the pattern you get all tags. Add --sort=-v:refname to see the newest version first.
The Releases page, or its Tags tab, on the right side of the repository page.
git describe --tagsSee which version the code in your folder is closest to.
Names the nearest tag behind your current commit. v1.4.1 means you are exactly on that release; v1.4.1-3-g9c4a2d7 means three commits after it, at commit 9c4a2d7.
git tag --contains <commit>See which releases include a commit.
Lists every tag that already contains the commit. If the list starts at v1.4.1, the fix shipped in 1.4.1; an empty list means it hasn't been released yet, even if it is merged.
Open the commit page: the tags that contain it are listed under the commit message.
git branch -r --contains <commit>Check whether a commit has reached main (or any other branch on GitHub).
Lists the GitHub branches that contain the commit, as of your last git fetch. If origin/main is on the list, it is merged. If your team squash-merges, use the commit hash shown on the merged pull request, not one from the branch.
The commit page lists the branches that contain it under the commit message.
git log --oneline <tag>..<tag>List everything that went in between two releases.
Put the older tag first, for example v1.4.0..v1.5.0: you get the commits in 1.5.0 that were not in 1.4.0. With squash merges that is one line per pull request, a ready draft for release notes.
Open /compare/v1.4.0...v1.5.0 in the repository, or use Generate release notes when drafting a release.
git tag -a <tag> -m "<text>"Mark the current commit as a release with a version tag.
Creates an annotated tag, with your name, the date and a note, on the commit you are on, for example v1.5.0. It stays on your laptop until you push it.
Tags are meant never to move: tag the wrong commit and push it, and people and tools may already have used that version before you fix it.
Releases → Draft a new release, type the new tag and pick the target branch; GitHub creates the tag when you publish.
git push origin <tag>Publish a tag to GitHub.
A plain git push doesn't send tags; this sends one. Many teams have automation that builds or deploys a release as soon as a version tag arrives.
Pushing the tag can start a real release or deploy, and everyone now sees that version.
Publishing a release on GitHub creates and publishes its tag in one step.
git cherry-pick <commit>Copy one commit onto your current branch, for example a fix onto a release branch.
Teams with release branches use it to ship an urgent fix without everything else that is waiting in main. The copy gets a new hash, so the same change appears twice in history.
It adds a commit to whichever branch you are on and can stop with a conflict; git cherry-pick --abort backs out.
Ten situations per round. Pick the command that does the job; after you answer, every option explains why it fits or doesn't.
You've solved 0 of 22 situations at least once.
"It's merged," says Daniel about the checkout fix. You want to confirm that commit 3f9a2c1 really is on main. Which command tells you?
Take the free Git course: Git and GitHub for Product People
On the blog: Git for product managers: read the repository, skip the command line
On the blog: How to review a pull request as a product manager (without reviewing code)
On the blog: Semantic versioning explained: what v1.4.1 means and when a change is really live