Merge
A merge is an operation in a version control system (e.g., Git) that combines changes from one branch into another. Simply put, a merge is a way to “integrate” code you’ve been working on separately back into the project’s main branch, while preserving the complete change history.
What is a Merge
A merge is used when you want to combine two development branches into one. This most commonly happens when a developer completes work on a task in a separate branch (e.g., feature/add-login) and wants to add the result to the main branch (main or develop).
Example: You created a new feature in your branch. After reviewing the code via a Pull Request, you perform a merge, and the changes become part of the main project.
How Merge Works
During a merge, Git compares three states of the project:
- The common ancestor (the point where the branches diverged).
- The current branch.
- The branch to be merged.
After analyzing the differences, Git combines the changes and creates a new merge commit to record the result.
Example command:
bash
git merge feature/add-login
This command will merge the feature/add-login branch into the current branch (e.g., develop).
Types of Merge
| Type | Description |
| Fast-forward merge | Occurs if the target branch hasn’t changed since branching. The history is simply “fast-forwarded” without creating a new commit. |
| No fast-forward (regular merge) | Creates a new merge commit that combines both branches, preserving their independent histories. |
| Squash merge | Combines all commits from the source branch into a single commit before merging — useful for a clean history. |
| Rebase + merge | The source branch’s history is rewritten on top of the target branch, resulting in a linear history. |
Example of a Fast-forward Merge
bash
git checkout main
git merge feature/header
If there have been no new commits in main, Git will simply move the branch pointer forward, resulting in a linear history without an extra commit.
Example of a Regular Merge
bash
git checkout develop
git merge feature/payment
If there are changes in both branches, Git creates a merge commit:
text
Merge branch ‘feature/payment’ into ‘develop’
This commit records that the branches were merged.
Merge Conflicts
Sometimes Git cannot automatically combine changes — for example, if different edits were made to the same line in the same file. This is called a merge conflict.
Example conflict:
text
<<<<<<< HEAD
console.log(‘Добро пожаловать!’);
=======
console.log(‘Welcome!’);
>>>>>>> feature/translation
Resolution:
- Manually choose the desired version or combine both.
- Remove the conflict markers: <<<<<<<, =======, >>>>>>>.
- Save the file and execute:
- bash
git add <filename>
- git commit
Example Workflow
bash
# Create a branch for a task
git checkout -b feature/add-search
# Work and commit changes
git add .
git commit -m “feat: added catalog search”
# Return to the main branch
git checkout develop
# Merge the new feature
git merge feature/add-search
After this, the code from feature/add-search is added to develop.
You can then delete the feature branch:
bash
git branch -d feature/add-search
Merge and Pull Request
On platforms like GitHub or GitLab, the merge operation is most often performed via a Pull Request (or Merge Request). After reviewers have checked and approved the code, you click the “Merge” button, and the system automatically merges the branches.
On GitHub, you can choose the merge strategy:
- Merge commit — standard merge preserving history.
- Squash and merge — all commits from the branch are squashed into one.
- Rebase and merge — history becomes linear, without merge commits.
Advantages of Merge
- Preserves the complete change history. All commits and branches remain visible.
- Safe and predictable. Does not alter existing commits (unlike rebase).
- Suited for team collaboration. Convenient to use with Pull Requests for transparent review.
Disadvantages
- History can become cluttered. With many merge commits, history can branch out and lose clarity.
- Requires manual conflict resolution. Especially in large teams with active changes.
- Less clean history than with rebase. Sometimes developers prefer to use rebase before merging to achieve a linear history.
Merge vs. Rebase
| Criterion | Merge | Rebase |
| Preserves History | Yes, with a merge commit | No, history is rewritten |
| Conflict Risk | Occurs when merging branches | Can occur with each commit |
| Transparency | High — all branches are visible | History looks cleaner |
| Safety | Absolutely safe for public branches | Risky when altering shared history |
| Application | For team collaboration | For local clean-up before push |
Merge Best Practices
- Update your branch before merging:
- bash
- git pull origin main
- Run tests and linters — especially before merging into main.
- Use Pull Requests to allow team review.
- Delete temporary branches after a successful merge.
- If the history is cluttered, use squash or rebase for a cleaner result.
Conclusion
Merge is a core process in Git that combines code from different developers into a single, coherent project version. It ensures team synchronization, preserves change history, and makes development manageable.
