Git branches: merging, conflicts, and saving work in progress

"Branching is Git’s killer feature. It is extremely lightweight and encourages you to create a branch for every small idea."

1. Basic branch operations#

Building on Git 00, a branch is simply a “pointer.”

Creating and switching

# 现代方式 (推荐，Git 2.23+)
git switch -c feature/example    # 创建并切换到新分支
git switch master          # 切换回 master

# 传统方式 (依然有效)
git checkout -b feature/example
git checkout master

Listing and deleting

git branch                 # 列出本地所有分支 (* 号表示当前所在)
git branch -v              # 查看每个分支的最后一次提交
git branch -d feature/example    # 删除已合并的分支
git branch -D feature/example    # 强制删除未合并的分支 (慎用)

2. Two modes of merging: Merge#

When you merge the feature branch back into master, Git chooses its approach based on the topology of the commit history.

A. Fast-forward merge

If master has no new commits since the branches diverged, Git simply moves the pointer forward.

• Characteristics: No new merge commit is created, and the history remains perfectly linear.

B. Three-way merge

When both sides have diverged, Git performs a three-way merge using their common ancestor and the content at both tips. On successful completion, it creates a merge commit. The commonly used strategy for two-head merges today is ort; recursive, as seen in older material, is not a generic name for three-way merging.

Advanced: Forcing a merge commit (--no-ff)

Why is this useful?: A fast-forward loses the information that “a feature branch existed here.” In practice, we often use git merge --no-ff feature/example to force that branch history to remain visible, making later code audits easier.

3. Resolving conflicts: When Git cannot decide#

Git stops and asks you to resolve conflicts when overlapping content cannot be merged automatically. Modify/delete and rename operations can also conflict; conflicts are not limited to the same line.

Conflict markers

Git inserts markers into conflicting files:

<<<<<<< HEAD
这是你在当前分支 (master) 修改的内容
=======
这是你要合并进来的分支 (feature) 修改的内容
>>>>>>> feature/example

Resolution steps

1. Edit manually: Remove the markers and keep the code you want.
2. Mark as resolved: Run git add <file> to tell Git that the conflict is resolved.
3. Complete the merge: Run git commit.

4. Saving work in progress: git stash#

Scenario: You are developing a feature when an urgent bug requires switching branches, but your current code is unfinished.

git stash                  # 保存已追踪文件的改动
git stash -u               # 【重要】包含未追踪的新文件 (include-untracked)
git stash list             # 查看所有存档
git stash pop              # 应用最顶层存档；成功后删除，冲突时通常保留存档

5. Branching strategies: Merge vs. Rebase#

This is one of Git’s most enduring debates. The details of using Rebase are covered in Git 04, but it is important to understand the difference in philosophy here.

6. Feature branching workflow#

Core principles:

1. Make keeping master/main usable a team goal: Do not develop directly on it.
2. One branch per feature: feature/login, fix/issue-101.
3. Review before merging: When master is ahead, merge its changes into the feature branch to ensure the feature branch is healthy before merging it back into the mainline.

Limits of saving work in progress

A regular stash saves tracked changes in the working tree and index; -u also includes untracked files, while ignored files need separate consideration. You can first use git stash apply to inspect the restored changes, then explicitly run git stash drop. If you need to restore the original staged state, check when --index is applicable. Check the current state before merging, switching, or deleting branches; branch -D deletes a reference that could be used for recovery, but does not delete all old objects.