Branching: Creating, Switching, and Merging
Objective. Students create and switch between branches, perform fast-forward and three-way merges, and delete branches after successful integration.
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
What Is a Branch?
A Git branch is a lightweight, movable pointer to a specific commit in your repository's history. When you create a branch, Git simply creates a new pointer — it does not copy files or duplicate work. This makes branching in Git very fast and inexpensive compared to older version-control systems.
Branching lets you isolate work. You can develop a new feature, fix a bug, or experiment with a design idea without touching the code that is already working on `main`. When the work is ready, you bring it back through a merge.
Creating and Switching Branches
The essential commands are:
```
git branch feature/navigation # creates the branch
git switch feature/navigation # moves HEAD to it
```
Or in a single step:
```
git switch -c feature/navigation
```
The older equivalent is `git checkout -b feature/navigation`. Both forms work; `git switch` is the modern, purpose-built command recommended for day-to-day use.
`HEAD` is Git's pointer to the commit you are currently working on. When you switch branches, HEAD moves to the tip of that branch. Any new commits you make extend that branch, not the one you left.
Fast-Forward Merges
A fast-forward merge happens when the branch you are merging into (`main`) has not received any new commits since the feature branch was created. Git can simply move `main`'s pointer forward to the tip of the feature branch — no new merge commit is created.
```
git switch main
git merge feature/navigation
```
Git will print a message like `Fast-forward` and show which files changed. The history stays linear — clean and easy to read. This is the simplest and most common merge scenario.
Three-Way Merges
A three-way merge occurs when both branches have diverged — each has at least one commit the other does not share. Git identifies three points:
1. The common ancestor commit (where the branches split).
2. The tip of the current branch (`main`).
3. The tip of the branch being merged in.
Git combines the changes and automatically creates a merge commit — a commit with two parents. The resulting history is not linear; it shows the fork and the point of reunification. You can visualize this with:
```
git log --graph --oneline --all
```
The `--graph` flag draws ASCII art of the branch topology, `--oneline` keeps it compact, and `--all` shows every branch, not just the current one.
Merge Conflicts
If both branches edited the same line of the same file, Git cannot resolve the difference automatically. It pauses the merge and marks the file with conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`). You must open the file, decide which version to keep (or combine them), remove the markers, stage the resolved file with `git add`, and complete the merge with `git commit`. This is normal workflow — not an error in Git.
Deleting Branches
After a successful merge, the feature branch is no longer needed. Delete it to keep the repository tidy:
```
git branch -d feature/navigation
```
The `-d` flag is safe: Git refuses to delete a branch that has not been fully merged into its upstream or the current branch, and prints a warning telling you so. This protects work you might otherwise lose.
If you are certain you want to discard an unmerged branch — for example, a prototype you have decided to abandon — use the force-delete flag:
```
git branch -D feature/abandoned-idea
```
Use `-D` deliberately and sparingly. Once the pointer is deleted and the commits are not referenced anywhere else, Git's garbage collector will eventually remove them. Document your reasoning in the lab log whenever you force-delete.
Safety and Professional Practices
Branching is a key safety practice in professional development. Never commit directly to `main` in a team environment without a review process. All new work should live on a dedicated branch so that `main` always reflects a stable, known-good state.
In workplace settings, branches are often protected by repository rules (on platforms such as GitHub or GitLab) that require a pull request and at least one reviewer before merging. Understanding local branching mechanics is the foundation for participating in those workflows.
Before switching branches, confirm that your working directory and staging area are clean (`git status`). Uncommitted changes can follow you to the new branch or, in some cases, prevent the switch entirely. Always commit or stash your work before switching.
Reading the Repository Graph
After completing both merges in this lab, `git log --graph --oneline --all` will show two distinct shapes:
- The fast-forward merge will appear as a straight line — no fork.
- The three-way merge will show two lines diverging and then converging at the merge commit.
Being able to read this graph fluently is an essential skill. It tells you the full story of your project's development history at a glance.
Key terms8
Materials: Git workstation, provided starter repository, terminal, VS Code, lab log, Pro Git book chapter 3
Check: Instructor inspects repository graph showing correct fast-forward and three-way merge commits; lab log entry complete; student verbally explains the difference between the two merge types to instructor satisfaction.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
