Merging Branches and Resolving Conflicts

Merging combines changes from one branch into the branch you are currently on. It is the mechanism that turns isolated branch work into a shared project state.

A merge is straightforward when the changes can be combined automatically. A merge conflict occurs when different branches changed the same part of the same file in incompatible ways and Git cannot choose the correct result.

To merge main into development, first switch to development:

git checkout development

Then merge main:

git merge main

Development now includes its own commits plus the relevant changes from main.

To bring development into main, switch to main and merge development:

git checkout main git merge development

The branch named after git merge is the source of incoming changes. The current branch is the destination that receives them.

This current-branch rule is essential. The same command name produces a different result depending on which branch is checked out.

If one branch adds a file and another branch modifies a different file, Git can often combine the changes automatically. After the merge, the destination branch contains both sets of work.

A conflict can occur when two branches modify the same line or section differently.

• staging changes a line in 4.txt to one value.
• development changes the same line to another value.
• development then runs git merge staging.

Git cannot determine whether the staging value, the development value, or a combination should be kept. It stops the automatic merge and marks the file as conflicted.

The file then contains conflict markers that identify the competing sections. The developer must open the file and decide the final content.

The valid resolution may be:

• Keep the current branch's version.
• Keep the incoming branch's version.
• Combine parts of both.
• Replace both with a corrected result.

After editing, remove the conflict markers, save the file, stage the resolved result, and commit it:

git add . git commit -m "Resolve merge conflict"

The resolution commit records the chosen final content.

Once the branches contain compatible resolved content, later merges can proceed without repeating the same conflict.

Branches are valuable only if their useful work can be integrated. Merging provides that integration, while conflict resolution ensures that Git does not make a silent decision when human intent is required.

A conflict is therefore not simply a failure. It is a protection mechanism. Git recognizes that two valid histories disagree at the same location and requires an explicit decision.

This preserves control over the final code instead of arbitrarily discarding one contributor's work.

A safe merge sequence is:

1. Commit or preserve current work.
2. Switch to the branch that should receive changes.
3. Run git status and confirm the working tree is clean.
4. Run git merge <source-branch>.
5. If the merge succeeds, inspect the combined files.
6. If a conflict occurs, open each conflicted file.
7. Choose or construct the final intended content.
8. Remove conflict markers.
9. Stage the resolved files.
10. Commit the resolution.

Example: synchronize development with main, then merge development into main.

git checkout development git merge main

Review and test the combined development branch. Then:

git checkout main git merge development

This order allows development to absorb the latest main changes before main receives the completed development work.

Suppose development and staging both change the same ending of 4.txt.

While on development:

git merge staging

Git reports that automatic merging failed. Open 4.txt, inspect the marked versions, decide the correct final line, remove the markers, and save.

git add 4.txt git commit -m "Resolve 4.txt merge conflict"

The repository now has an explicit record of the resolution.

Merging can combine independent work automatically, but overlapping edits require manual judgment.

The developer resolving a conflict must understand the intended behavior. Git can show the competing text, but it cannot determine the correct business or technical decision.

Merging in the wrong direction updates the wrong branch. Always confirm the current branch before running git merge.

A conflict resolution is not complete when the file is merely edited. The resolved file must be staged and committed.

Merge into the branch that should receive changes. When Git cannot combine overlapping edits safely, resolve the file manually, stage the chosen result, and commit the resolution as part of project history.