Merging, Rebasing, and Conflict Resolution

Understand merge commits, fast-forward merges, rebasing, conflict resolution, and when to choose each integration strategy.

Merging Branches

Merging integrates the history of one branch into another. A fast-forward merge occurs when the target branch has not diverged and can simply move its reference forward. When branches have diverged, Git may create a merge commit that records both parent histories.

Merge Integration

Merge a Feature

git switch main
git merge feature/login
git log --oneline --graph --decorate --all

💡 The feature branch is merged into the currently checked-out main branch. Git chooses an appropriate merge strategy based on the relationship between the branches.

Key Takeaways

A merge preserves the original branch histories.
Fast-forward merging does not create an additional merge commit.
A merge commit can have two or more parents.

Knowledge Check

What is a fast-forward merge?

Rebasing

Rebase moves or replays commits onto a new base. It can create a cleaner, linear-looking history, but it rewrites commit identities because the replayed commits are new commits.

A common workflow is rebasing a feature branch onto the latest main before opening a pull request.

Rebase Rewrites History

Do not casually rebase commits that other developers have already based work on. Shared history rewriting can force collaborators to reconcile divergent commit identities.

Rebase a Feature Branch

git switch feature/login
git fetch origin
git rebase origin/main

💡 Git temporarily removes the feature commits, updates the base to origin/main, and replays those feature commits on top of it.

Key Takeaways

Rebase creates new commit identities for replayed commits.
Rebase can produce a linear history.
Avoid rewriting public history unless the team explicitly agrees.

Knowledge Check

Why does rebasing change commit hashes?

Resolving Merge Conflicts

A conflict occurs when Git cannot automatically reconcile changes, often because different branches modified overlapping lines. Git marks conflicted files with conflict markers such as <<<<<<<, =======, and >>>>>>>.

The resolution process is: inspect conflicts → edit the file into the desired final state → stage the resolved file → continue the merge or rebase.

Resolve a Merge Conflict

git status
# edit conflicted files
git add src/app.js
git commit

# During a rebase:
git add src/app.js
git rebase --continue

💡 After resolving the file contents, staging marks the conflict as resolved. During a merge, the next step is normally committing; during a rebase, use git rebase --continue.

Key Takeaways

Conflict markers must be removed from the final file.
Git considers a conflict resolved when the corrected file is staged.
git rebase --abort can safely cancel an in-progress rebase.

Knowledge Check

What should you normally do after manually resolving a conflicted file?

Interactive Rebase

Interactive rebase lets you reorganize, edit, squash, reorder, or drop commits before sharing them. It is particularly useful for cleaning up a feature branch before review.

Commands in an interactive rebase include pick, reword, edit, squash, fixup, and drop.

Clean Up Recent Commits

git rebase -i HEAD~4

# Example todo:
# pick abc123 Add login form
# squash def456 Fix login form
# reword 789abc Add validation
# pick 012def Add tests

💡 The interactive todo list determines how Git should replay the selected commits.

Key Takeaways

Interactive rebase is useful for local history cleanup.
squash combines commits while allowing message editing.
fixup combines commits while discarding the fixup commit's message.

Knowledge Check

What does `squash` do in an interactive rebase?

Merging Branches

Rebasing

Resolving Merge Conflicts

Interactive Rebase

STAY UPDATED WITH BYTES!