Click image to open full size
Computer Science
Version Control with Git
Commits, branches, merges, and collaboration with Git
Related Tools
Related Labs
Related Worksheets
Related Cheat Sheets
Git is a version control system that tracks changes in files over time, especially source code. It lets developers save snapshots called commits, compare versions, and return to earlier work when needed. Git matters because modern software is usually built by teams, and teams need a reliable way to coordinate edits without losing work. A Git history also records why a project changed, not just what changed.
Key Facts
- A commit is a saved snapshot of a project at a specific time.
- git status shows which files are modified, staged, or untracked.
- git add file.txt moves a file change into the staging area before committing.
- git commit -m 'message' records staged changes in the local repository.
- git branch feature creates a new branch, and git checkout feature or git switch feature moves to it.
- git pull = git fetch + git merge, which downloads remote changes and integrates them into the current branch.
Vocabulary
- Repository
- A repository is a project folder that Git tracks, including its files, history, branches, and configuration.
- Commit
- A commit is a recorded snapshot of staged changes with an identifier, author, timestamp, and message.
- Branch
- A branch is a movable pointer to a line of commits, often used to develop features without changing the main line.
- Merge
- A merge combines changes from one branch into another and may create a new merge commit.
- Remote
- A remote is a shared copy of a repository stored on another computer or service such as GitHub or GitLab.
Common Mistakes to Avoid
- Committing without checking git status is wrong because you may record missing files, unwanted debug code, or unrelated changes.
- Using git add . carelessly is wrong because it can stage temporary files, secrets, or large generated files that should not enter the repository.
- Pulling remote changes without saving local work is risky because uncommitted edits can conflict with incoming changes or make the update harder to understand.
- Resolving a merge conflict by deleting code you do not recognize is wrong because both sides may contain important work that must be compared and integrated carefully.
Practice Questions
- 1 A repository has commits A, B, and C on main. You create a feature branch from B and add commits D and E. How many commits are on the feature branch history, including inherited commits?
- 2 A project has 12 modified files. You run git add on 7 of them, then commit. How many modified files remain unstaged after the commit if no other changes occur?
- 3 A teammate pushes new commits to main while you are working on a feature branch. Explain why pulling or merging main into your branch before opening a pull request can reduce integration problems.