Version Control with Git Cheat Sheet

A printable reference covering Git repositories, commits, branches, merges, pull requests, and common commands for grades 9-12.

Download PNG

Related Tools

Related Labs

Related Worksheets

Related Infographics

Version control with Git helps students save, track, compare, and share changes in code projects. This cheat sheet gives a quick reference for the commands and ideas used in real software development. Students need Git to recover earlier work, collaborate safely, and understand how professional programming teams manage code. It is especially useful for class projects, coding clubs, and portfolio work.

Key Facts

git init creates a new Git repository in the current folder.
git status shows which files are modified, staged, untracked, or clean.
git add file stages a file, and git add . stages all changed files in the current folder and its subfolders.
git commit -m "message" saves the staged changes as a permanent snapshot with a unique commit hash.
git log --oneline shows the commit history in a compact list of short hashes and commit messages.
git branch name creates a new branch, but it does not switch to that branch.
git switch -c name creates a new branch and switches to it in one step.
git pull equals git fetch plus git merge, so it downloads remote changes and then combines them into the current branch.

Vocabulary

Repository: A repository is a project folder that Git tracks, including its files, history, branches, and settings.
Commit: A commit is a saved snapshot of staged changes with a message, author, time, and unique hash.
Branch: A branch is a movable pointer to a line of commits, often used to develop a feature without changing main.
Merge: A merge combines the changes from one branch into another branch.
Remote: A remote is a linked copy of a repository stored somewhere else, such as GitHub, GitLab, or a school server.
Pull Request: A pull request is a request to review and merge changes from one branch into another, usually on a hosting site.

Common Mistakes to Avoid

Committing without staging files is wrong because git commit only saves files that were added to the staging area with git add.
Writing vague commit messages is wrong because messages like "stuff" or "fixed" do not explain what changed or help future readers.
Working directly on main is risky because unfinished or broken code can affect the stable version of the project.
Ignoring merge conflicts is wrong because Git needs a human to choose the correct final version when two changes overlap.
Using git pull without checking status first can cause confusion because uncommitted local changes may conflict with incoming remote changes.

Practice Questions

1 A project has 12 commits on main. You create a feature branch and add 4 commits there. How many commits are on the feature branch if it started from the latest main commit?
2 Your local branch is 3 commits behind origin/main and 2 commits ahead of origin/main. After a successful git pull that merges the remote commits, how many remote commits were downloaded?
3 Write the Git commands to create a new branch named navbar-fix, switch to it, stage all changed files, and commit with the message "Fix navbar layout".
4 Explain why a team should use branches and pull requests instead of letting everyone push directly to main.