Merging Branches — What It Is, Merge Strategies, and Conflict Resolution

What Is Merge in Git

Merge in Git is the operation of combining two or more development histories into one. When a developer merges a branch, Git automatically finds the common ancestor (base commit) and creates a new merge commit that includes changes from both branches. Three-way merge is the standard algorithm that compares three states: the common ancestor, the first branch, and the second branch.

The merge process begins with the git merge command. Git determines the point where the branches diverged and sequentially applies changes from the source branch onto the target branch. If the changes do not conflict, Git performs a fast-forward or creates a merge commit depending on the settings. Fast-forward is a scenario where the target branch simply moves forward to the source branch’s commits.

# Switch to target branch and merge
git checkout main
git merge feature/payment-module

# Merge with explicit no-fast-forward
git merge --no-ff feature/payment-module

# Abort merge if conflicts are too complex
git merge --abort

The --no-ff flag (no fast-forward) forces the creation of a merge commit even when a fast-forward is possible. This preserves information that the changes were made in a separate branch. Many teams prefer this approach to maintain explicit branching history.

Branch Merging Methods

Git has three main branch merging strategies, each suitable for a specific scenario. The choice of strategy depends on the team’s culture and requirements for the cleanliness of the project history.

Standard merge creates a merge commit with two parents. The full history is preserved, but the branching graph becomes more complex. Squash merge combines all commits of a feature branch into one and applies it on top of the target branch — the history becomes linear and clean, but information about intermediate stages is lost.

Rebase, although not a full-fledged merge, achieves the same result — changes from one branch are moved on top of another. The difference is that history is rewritten: commits of the feature branch are recreated on top of the latest commit of the target branch. This gives a perfectly linear history but requires a force push when uploading.

How to Resolve Merge Conflicts

A merge conflict occurs when the same lines of a file are changed in two branches. Git cannot automatically determine which version to keep and requires developer intervention. Conflicts are displayed in files using special markers: <<<<<<<, =======, >>>>>>>.

The conflict resolution process involves several steps. First, the developer opens the conflicting file and manually selects the needed changes. It is important not just to choose one version but to understand the logic of both changes and make a correct decision. After editing the file, the conflict markers are removed, and the changes are added to the staging area via git add.

# View list of conflicted files
git status

# Start mergetool (e.g., VS Code, IntelliJ)
git mergetool

# After resolving all conflicts
git add .
git merge --continue

# Or abort the merge entirely
git merge --abort

Using visual merge tools significantly speeds up conflict resolution. VS Code, IntelliJ IDEA, and GitKraken provide interfaces with three panels: current branch, incoming branch, and result. The git mergetool command automatically opens the configured editor for each conflicting file.

The best way to avoid complex conflicts is regular synchronization of the feature branch with the main branch. If a developer merges main into their branch once a day, conflicts will be small and easily resolvable. Accumulating changes over a week guarantees complex conflicts with a high risk of errors.

When to Use Rebase Instead of Merge

Rebase and merge are two ways of combining changes, and the choice between them often sparks debates in teams. Rebase moves commits from one branch on top of another, rewriting history. Merge creates a new merge commit, preserving branching history. Each approach has its advantages and limitations.

Rebase is appropriate when a developer is working on their local feature branch and wants a clean linear history before creating a Pull Request. After rebase, all commits are arranged sequentially without unnecessary merge commits. However, rebase requires force push and is not applicable to branches where multiple people work simultaneously.

• Rebase — for personal feature branches where clean history is needed
• Merge — for shared branches and recording the merge point
• Squash — when a feature branch contains many small draft commits

The golden rule of Git: do not use rebase on commits that have already been pushed to the shared repository. This ensures that the history in the shared branch remains unchanged and other developers will not encounter duplicate or lost commits. For integrating a feature branch into the main branch, use merge via Pull Request.

Best Practices for Branch Merging

A proper merge process is the foundation of stable development. In modern teamwork, merging is done not through the console but via Pull Request on GitHub or Merge Request in GitLab. A PR goes through code review, automated CI checks, and only then is merged into the main branch.

The first practice — merge only after all checks pass. The CI pipeline should build the project, run tests, and verify code quality. If at least one check fails, the merge is blocked. Modern platforms (GitHub, GitLab) have built-in protection: branch protection rules automatically block merging if CI fails.

The second practice — never merge broken code. Before merging, the developer must ensure their changes do not break the build or regress existing functionality. Automated tests and code review serve this purpose.

The third practice — clean up feature branches after merging. A branch that has been merged should be deleted. This prevents confusion and clutter in the repository. GitHub automatically offers to delete a branch after a PR is merged, and repository settings can be configured for automatic deletion.