Git Merge Conflict Resolution and Behavior

combined history; instead, the `HEAD` (along with the index) is updated to point at the named commit, without creating an extra merge commit. This behavior can be suppressed with the `--no-ff` option. TRUE MERGE ---------- Except in a fast-forward merge (see above), the branches to be merged must be tied together by a merge commit that has both of them as its parents. A merged version reconciling the changes from all branches to be merged is committed, and your `HEAD`, index, and working tree are updated to it. It is possible to have modifications in the working tree as long as they do not overlap; the update will preserve them. When it is not obvious how to reconcile the changes, the following happens: 1. The `HEAD` pointer stays the same. 2. The `MERGE_HEAD` ref is set to point to the other branch head. 3. Paths that merged cleanly are updated both in the index file and in your working tree. 4. For conflicting paths, the index file records up to three versions: stage 1 stores the version from the common ancestor, stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you can inspect the stages with `git ls-files -u`). The working tree files contain the result of the merge operation; i.e. 3-way merge results with familiar conflict markers +<<<+ `===` +>>>+. 5. A ref named `AUTO_MERGE` is written, pointing to a tree corresponding to the current content of the working tree (including conflict markers for textual conflicts). Note that this ref is only written when the `ort` merge strategy is used (the default). 6. No other changes are made. In particular, the local modifications you had before you started merge will stay the same and the index entries for them stay as they were, i.e. matching `HEAD`. If you tried a merge which resulted in complex conflicts and want to start over, you can recover with `git merge --abort`. MERGING TAG ----------- When merging an annotated (and possibly signed) tag, Git always creates a merge commit even if a fast-forward merge is possible, and the commit message template is prepared with the tag message. Additionally, if the tag is signed, the signature check is reported as a comment in the message template. See also linkgit:git-tag[1]. When you want to just integrate with the work leading to the commit that happens to be tagged, e.g. synchronizing with an upstream release point, you may not want to make an unnecessary merge commit. In such a case, you can "unwrap" the tag yourself before feeding it to `git merge`, or pass `--ff-only` when you do not have any work on your own. e.g. ---- git fetch origin git merge v1.2.3^0 git merge --ff-only v1.2.3 ---- HOW CONFLICTS ARE PRESENTED --------------------------- During a merge, the working tree files are updated to reflect the result of the merge. Among the changes made to the common ancestor's version, non-overlapping ones (that is, you changed an area of the file while the other side left that area intact, or vice versa) are incorporated in the final result verbatim. When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area. By default, Git uses the same style as the one used by the "merge" program from the RCS suite to present such a conflicted hunk, like this: ------------ Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed, or cleanly resolved because both sides changed the same way. <<<<<<< yours:sample.txt Conflict resolution is hard; let's go shopping. ======= Git makes conflict resolution easy. >>>>>>> theirs:sample.txt And here is another line that is cleanly resolved or unmodified. ------------ The area where a pair of conflicting changes happened is marked with markers +<<<<<<<+, `=======`, and +>>>>>>>+. The part before the `=======` is typically your side, and the part afterwards is typically their side.

When a git merge encounters conflicts, it updates the working tree and index to reflect the merged changes, leaving conflict markers for unresolved areas, and provides options to recover from complex conflicts or start over with `git merge --abort`, while also handling merges with annotated tags and presenting conflicts in a standard format.