Merge
murj
Combining code changes from one branch into another, integrating the work.
A merge is the act of combining code changes from one branch into another. When a feature branch is merged into main, the changes become part of the production codebase. Merging is the final step in the branch-review-merge workflow.
Most merges are automatic. Git compares the two branches, applies the changes, and creates a merge commit. When two branches modify the same lines of code, a merge conflict occurs and a developer must manually resolve which version to keep.
Merge strategies matter. A regular merge preserves the full branch history. A squash merge condenses all branch commits into a single commit on main, creating a cleaner history. A rebase replays commits on top of main, creating a linear history. Teams choose based on how much history granularity they want.
Examples
A feature branch is ready to ship.
After code review approval and passing CI checks, the developer clicks 'Squash and merge' on the PR. All 12 commits from the feature branch are condensed into a single commit on main with a clear description. The feature branch is automatically deleted.
A merge conflict needs resolution.
Two developers modified the same configuration file. When the second developer tries to merge, Git flags the conflict. The developer opens the file, sees both versions marked with conflict markers, chooses the correct combination of both changes, and commits the resolution.
A bad merge breaks production.
A merge introduces a bug that passes CI but fails under production load. The team reverts the merge commit, which cleanly undoes all the changes in a single operation. Production recovers. The developer fixes the bug on their branch and re-merges after additional testing.
In practice
Read more on the blog
Frequently asked questions
What is the difference between merge, squash, and rebase?
A merge preserves all commits and creates a merge commit. A squash merge condenses all branch commits into one commit. A rebase replays your commits on top of the latest main, creating a linear history. Squash merge is most common for feature branches because it keeps the main branch history clean.
How do you avoid merge conflicts?
Keep branches short-lived (a few days, not weeks). Pull from main frequently to stay up to date. Communicate with teammates when working on the same files. Break large changes into smaller, independent PRs that are less likely to overlap.
Related terms
A parallel version of the code that lets developers work on changes without affecting the main codebase.
A proposal to merge code changes from one branch into another, with review.
The practice of having other developers examine code changes before they are merged.
Continuous integration and continuous deployment: automating code testing and delivery to production.
Reverting a deployment to a previous known-good version when the new version causes problems.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.