Merge
You might say
The feature I built separately works. How do I bring it back into the main version?
Combine the commits from one branch into anotherMerge brings two lines of history together. Git can combine independent changes automatically, but overlapping edits may create conflicts that a person must resolve. Review the result and run tests after resolving, because a clean text merge can still break behavior.
You can say this to an AI Agent
Merge this feature branch into its target. First inspect what each side must preserve, resolve the conflict, confirm no markers remain, and run relevant tests. Report the merge and test results; do not resolve it by arbitrarily choosing one side.
When to use it
- Bring a reviewed feature into mainmain
- Combine work from two branchesmain
- Keep both lines of history<<<<<<< HEADTitle: Xiaoli's home page=======Title: Xiaoli's photography home page>>>>>>> feature
- Integrate a finished fixEdit final content→git add→git commit
When NOT to use it
- Resolve a conflict without understanding both sidesThe feature branch still has an error→ merge →main has the same bugMerging unverified changes into main raises release risk
- Merge into the wrong target branch
Title: Xiaoli's home pageTitle: Xiaoli's photography home pageDeleting both sides can remove existing functionality - Assume no text conflict means no product conflict<<<<<<< HEAD
Title: Xiaoli's home pageLeaving conflict markers can make code unparsable - Mix unrelated cleanup into conflict resolutionmerge ✓→push ✓→Production error
Anatomy
<<<<<<< HEAD
<h1>Xiaoli's homepage</h1>
=======
<h1>Xiaoli’s photography homepage</h1>
>>>>>>> feature/new-nav
Starting here is the conflict area, HEAD refers to the version of the branch you are currently on.
What does this line look like on the current branch? It is usually the content of the main line.
The boundary between the upper and lower versions must be deleted together when resolving the conflict.
What does this line look like on the merged branch?
The conflict area ends here, marking which branch the content comes from.
Variants
Fast-forward
Updating a3f9c21..e7b2d48
The target branch has no independent new commits
Merge Commit
Merge made by the 'ort' strategy.
There are new commits on both sides and the merge node needs to be retained
merge --abort
git merge --abort
When you need to abandon the current unfinished merge
Typical use cases
Feature integration
$ git switch main
Switched to branch 'main'
$ git merge feature/new-nav
Merge made by the 'ort' strategy.
index.html | 24 ++++++++++++++-----
1 file changed, 16 insertions(+), 8 deletions(-)
Pull request merge
Release preparation
Conflict resolution
Git merge vs rebase: which should you use?
Use Merge as the safer default for shared commits. Consider Rebase on an unshared personal branch when you want a linear history before review.
| Decision point | Git Merge | Git Rebase |
|---|---|---|
| Commit history | Preserves true branch history and explicit merge commits (or fast-forwards the branch pointer). | Replays commits onto a new base, generating new commit hashes to produce a linear history. |
| Collaboration | Keeps existing commit IDs, making shared history easier to integrate. | Creates new commit IDs; rewriting shared history requires explicit team coordination. |
| When to use | Merging a feature into main or integrating a shared team branch. | Cleaning up an unshared personal branch or replaying it onto the latest main before review. |
Recommended tool
Web fine-tuning tool · Selector Pro
Select page elements for precise AI edits
Click a button, text, or card, note the change, then copy its exact location to AI.
Open Selector Pro website↗Further reading
Quick check