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.
Understanding Version Control with Git
Git works like a timeline made from linked snapshots. Each commit records the project state at one moment, along with a message, author, time, and a link to earlier commits. Git usually stores changes efficiently rather than making a full duplicate of every file each time.
This makes it possible to inspect what changed between two points in the timeline. A commit is not simply a save button.
It is a deliberate record of a meaningful step, such as adding a login screen or fixing an error in a calculation. Clear commit messages make that timeline useful months later.
Before a commit, Git separates work into areas. The working folder contains the files being edited right now. The staging area is a planned list of changes for the next commit.
This extra step can feel inconvenient at first, but it gives control. A student may change three files while testing an idea, then stage only the two files that complete one feature.
The unfinished experiment stays out of the commit. Checking status often prevents common mistakes, including forgetting a new file or committing a generated file that does not belong in the project.
Branches allow different lines of work to exist without disturbing the main version of a project. A new branch begins at a particular commit. From there, its commits form a separate path until the work is combined.
This is useful when one person designs a new page while another corrects bugs. A merge joins the histories when the changes fit together. Sometimes both branches edit the same part of the same file.
Git cannot always decide which version is correct, so it marks a merge conflict. The programmer must read the conflicting versions, choose or combine the intended code, test it, then commit the resolved result.
Conflicts are normal. Careful reading matters more than speed.
Many projects use a remote repository on a service such as GitHub. The remote is a shared copy that can be reached over the internet. Pushing sends local commits to it.
Fetching downloads information about other people's commits without changing current files. Pulling first fetches, then tries to merge those updates into the current branch. A pull request is a discussion and review process around proposed branch changes before they reach the main branch.
Students should pull before starting shared work, make small focused commits, and read changes before merging. They should never store passwords, private keys, or personal data in a repository, even if it is later deleted. Earlier commits may still contain that information.