Git branching lets developers work on new features, fixes, and experiments without changing the main version of a project right away. This cheat sheet helps students understand how branches split, move, and come back together. It is useful for class coding projects, team collaboration, and keeping a clean project history.
Knowing merge strategies also helps students avoid lost work and confusing conflicts.
Key Facts
- Create and switch to a new branch with git switch -c branch-name, which makes a branch pointer and checks it out.
- List local branches with git branch, and the currently checked-out branch is marked with an asterisk.
- A fast-forward merge happens when the target branch has no new commits, so Git simply moves the branch pointer forward.
- A three-way merge uses the two branch tips and their common ancestor to create a new merge commit.
- Rebase with git rebase main rewrites commits from the current branch so they appear after the latest commit on main.
- Resolve a merge conflict by editing the conflicted file, running git add file-name, then completing the merge with git commit or git rebase --continue.
- Pull updates safely with git pull, which is usually equivalent to git fetch followed by git merge for the current tracking branch.
- Delete a merged local branch with git branch -d branch-name, but use git branch -D branch-name only when you intentionally want to force deletion.
Vocabulary
- Branch
- A branch is a movable pointer to a commit that lets you work on a separate line of development.
- Commit
- A commit is a saved snapshot of project changes with an ID, author, message, and link to previous commits.
- Merge
- A merge combines changes from one branch into another branch.
- Fast-forward
- A fast-forward is a merge where Git only moves the target branch pointer forward because there are no separate commits to combine.
- Rebase
- A rebase reapplies commits from one branch onto the tip of another branch to create a straighter history.
- Merge conflict
- A merge conflict happens when Git cannot automatically decide how to combine competing changes in the same part of a file.
Common Mistakes to Avoid
- Merging the wrong direction, such as merging main into a feature branch when the goal is to finish the feature, is wrong because it does not place the feature work onto main.
- Using git branch branch-name and expecting to switch branches is wrong because git branch only creates or lists branches unless paired with a checkout or switch command.
- Rebasing shared commits is risky because rewriting history can confuse teammates who already based work on the old commits.
- Ignoring conflict markers like <<<<<<<, =======, and >>>>>>> is wrong because those markers are not valid final code and must be edited out manually.
- Forcing branch deletion with git branch -D without checking the work is wrong because unmerged commits may become hard to find or recover.
Practice Questions
- 1 You are on main and need to start a feature called login-form. What command creates the branch and switches to it in one step?
- 2 A branch feature has 4 commits after splitting from main, and main has 0 new commits. What merge strategy will Git likely use when merging feature into main?
- 3 A branch feature has 3 commits after splitting from main, and main has 2 new commits after the split. Why is this not a fast-forward merge?
- 4 A teammate suggests using rebase on a branch that has already been pushed and used by others. Explain why a merge may be safer for collaboration.
Understanding Git Branching & Merge Strategies
Git history is easier to understand when you picture commits as saved snapshots linked to earlier snapshots. Each commit has an identity, a message, an author, and a link to its parent commit. A branch is only a movable label that points at one commit.
When you make a new commit while that branch is checked out, the label moves forward. This is why creating branches is quick. Git does not copy every project file into a separate folder each time.
A merge is about joining lines of history, not just combining files. If one line has moved ahead while the other has stayed still, Git can move the older label to the newer commit without creating extra history. If both lines contain new commits, Git compares their shared starting point with the changes on each line.
It then creates a result based on those comparisons. A merge commit records that the project now has two parent histories. This can make team history easier to trace later.
Rebasing produces a different shape of history. It takes commits from one line and recreates them after a newer commit from another line. The file changes may look similar, but the recreated commits are new commits with new identities.
This matters when work has already been shared with classmates. If someone else based work on the old commits, rewriting them can cause confusion when their copies try to reconnect. Rebasing is usually safest for private work that only one person has used.
A conflict does not mean Git has failed or that either person made a mistake. It means Git found overlapping edits and cannot know which meaning is correct. Conflict markers show the competing pieces of text.
Read the surrounding code before choosing a version. Sometimes the correct answer is to combine both edits or write a new version.
Run the program and any tests after resolving a conflict. A file can be free of conflict markers yet still contain a logical bug.
Pull requests add a review step before shared code becomes part of the project. Good pull requests stay focused on one task, use clear commit messages, and explain how the change was tested. Reviewers can spot missing cases, unclear names, or accidental changes to unrelated files.
In a school project, agree on branch names, who reviews changes, and when main is updated. Before merging, check the changed files carefully and confirm that the final history matches the team plan. Keeping small commits makes mistakes easier to locate and undo.