Combining two lines of work
Merging integrates the changes made on one branch into another — taking a finished search feature on feature/search into main, for example.
Git examines what each branch did since they diverged and tries to combine both. On GitHub, the usual flow is to review a pull request and then press Merge.
How it differs from pull
Merging is the mechanism that combines branch histories. Pulling is the sequence that fetches remote changes and integrates them into your current branch — and by default, that integration uses a merge.
Merge conflicts
When the same line differs between two branches, Git cannot decide which to keep. That state is a merge conflict.
A conflict is not a failure; it is a request for human judgment. Look at why each side changed, edit the result you want to keep, and commit.
Before merging
- Is the direction correct?
- Have tests and visual checks been done?
- Are there stray files or secrets included?
- Have review comments been resolved?
Some projects deploy automatically after a merge. Know how merging into main connects to going live.
What the history looks like afterward
Depending on the shape of the history, Git may simply move the branch pointer forward — a fast-forward — or create a merge commit recording that two lines were combined.
GitHub pull requests may also offer squash merge, which combines the commits into one, and rebase merge, which replays them. Which is correct depends on the project’s conventions. If you are new, follow the existing rule rather than changing the method yourself.