The `git merge` command combines the work from one branch into another. The most common scenario is merging a finished feature branch back into your main branch.

## Basic merge

First, switch to the branch you want to merge *into*, then run `git merge` with the name of the branch you want to bring in:

```bash
$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

$ git merge my-new-feature
Updating 56aedbe..0dda643
Fast-forward
 assets/images/cheese/edam.svg | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 assets/images/cheese/edam.svg
```

The output shows the commit range that was merged and a summary of changed files. Your main branch now includes all the work from `my-new-feature`. For more on how this fits into a typical workflow, see [Branching and Merging](/git/branching-and-merging).

## Fast-forward vs three-way merge

Git uses two strategies depending on the branch history:

- **Fast-forward**: If `main` hasn't changed since you branched off, Git simply moves the `main` pointer forward to the latest commit on your feature branch. No new commit is created. This is what happened in the example above.
- **Three-way merge**: If `main` has new commits that your feature branch doesn't have, Git creates a new "merge commit" that ties the two histories together.

## Using --no-ff

Sometimes you want a merge commit even when a fast-forward is possible, to keep a clear record that a feature branch existed:

```bash
$ git merge --no-ff my-new-feature
Merge made by the 'ort' strategy.
 assets/images/cheese/edam.svg | 1 +
 1 file changed, 1 insertion(+)
```

This creates a merge commit regardless, which makes `git log --graph` easier to follow on long-running projects.

## Handling merge conflicts

If both branches changed the same lines in a file, Git can't automatically combine them. You'll see something like:

```bash
$ git merge my-new-feature
Auto-merging src/menu.js
CONFLICT (content): Merge conflict in src/menu.js
Automatic merge failed; fix conflicts and then commit the result.
```

Open the conflicting file, look for the `<<<<<<<`, `=======`, and `>>>>>>>` markers, and decide which changes to keep. Once you've resolved all conflicts, stage the files and commit:

```bash
$ git add src/menu.js
$ git commit
```

For a detailed walkthrough, see [How to resolve merge conflicts](/git/faqs/resolve-merge-conflicts-git).

## Aborting a merge

If you start a merge and decide you don't want to continue (perhaps the conflicts are more complex than expected), you can back out cleanly:

```bash
$ git merge --abort
```

This resets your working directory to the state before the merge began. No changes are lost from either branch.

## Merge vs rebase

Both `git merge` and [git rebase](/git/commands/git-rebase) integrate changes from one branch into another, but they do it differently. Merging preserves the full branch history with a merge commit, while rebasing replays your commits on top of the target branch for a linear history. Merging is the safer default — use it unless your team has agreed on a rebase workflow.

## Related: managing branches

See [git branch](/git/branching-and-merging) for creating, listing, and deleting branches.

Once your branches are merged, [DeployHQ](https://www.deployhq.com) can automatically deploy the result to your server — trigger deployments on push to `main`, or map different branches to different environments.