doc: git-merge: link to new merge conflicts guide
All of the info about merge conflicts has been moved to the new guide Signed-off-by: Julia Evans <julia@jvns.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>seen
Julia Evans
Junio C Hamano
parent
a957f40694
commit
4a1237aa8a
|
|
@ -49,7 +49,8 @@ a log message from the user describing the changes. Before the operation,
|
|||
A merge stops if there's a conflict that cannot be resolved
|
||||
automatically or if `--no-commit` was provided when initiating the
|
||||
merge. At that point you can run `git merge --abort` or `git merge
|
||||
--continue`.
|
||||
--continue`. See linkgit:gitmergeconflicts[7]
|
||||
(or `git help mergeconflicts`) for a guide to handling merge conflicts.
|
||||
|
||||
`git merge --abort` will abort the merge process and try to reconstruct
|
||||
the pre-merge state. However, if there were uncommitted changes when the
|
||||
|
|
@ -231,127 +232,6 @@ 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.
|
||||
|
||||
The default format does not show what the original said in the conflicting
|
||||
area. You cannot tell how many lines are deleted and replaced with
|
||||
Barbie's remark on your side. The only thing you can tell is that your
|
||||
side wants to say it is hard and you'd prefer to go shopping, while the
|
||||
other side wants to claim it is easy.
|
||||
|
||||
An alternative style can be used by setting the `merge.conflictStyle`
|
||||
configuration variable to either `diff3` or `zdiff3`. In `diff3`
|
||||
style, the above conflict may look like this:
|
||||
|
||||
------------
|
||||
Here are lines that are either unchanged from the common
|
||||
ancestor, or cleanly resolved because only one side changed,
|
||||
<<<<<<< yours:sample.txt
|
||||
or cleanly resolved because both sides changed the same way.
|
||||
Conflict resolution is hard;
|
||||
let's go shopping.
|
||||
||||||| base:sample.txt
|
||||
or cleanly resolved because both sides changed identically.
|
||||
Conflict resolution is hard.
|
||||
=======
|
||||
or cleanly resolved because both sides changed the same way.
|
||||
Git makes conflict resolution easy.
|
||||
>>>>>>> theirs:sample.txt
|
||||
And here is another line that is cleanly resolved or unmodified.
|
||||
------------
|
||||
|
||||
while in `zdiff3` style, it may look 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.
|
||||
||||||| base:sample.txt
|
||||
or cleanly resolved because both sides changed identically.
|
||||
Conflict resolution is hard.
|
||||
=======
|
||||
Git makes conflict resolution easy.
|
||||
>>>>>>> theirs:sample.txt
|
||||
And here is another line that is cleanly resolved or unmodified.
|
||||
------------
|
||||
|
||||
In addition to the +<<<<<<<+, `=======`, and +>>>>>>>+ markers, it uses
|
||||
another +|||||||+ marker that is followed by the original text. You can
|
||||
tell that the original just stated a fact, and your side simply gave in to
|
||||
that statement and gave up, while the other side tried to have a more
|
||||
positive attitude. You can sometimes come up with a better resolution by
|
||||
viewing the original.
|
||||
|
||||
|
||||
HOW TO RESOLVE CONFLICTS
|
||||
------------------------
|
||||
|
||||
After seeing a conflict, you can do two things:
|
||||
|
||||
* Decide not to merge. The only clean-ups you need are to reset
|
||||
the index file to the `HEAD` commit to reverse 2. and to clean
|
||||
up working tree changes made by 2. and 3.; `git merge --abort`
|
||||
can be used for this.
|
||||
|
||||
* Resolve the conflicts. Git will mark the conflicts in
|
||||
the working tree. Edit the files into shape and
|
||||
`git add` them to the index. Use `git commit` or
|
||||
`git merge --continue` to seal the deal. The latter command
|
||||
checks whether there is a (interrupted) merge in progress
|
||||
before calling `git commit`.
|
||||
|
||||
You can work through the conflict with a number of tools:
|
||||
|
||||
* Use a mergetool. `git mergetool` to launch a graphical
|
||||
mergetool which will work through the merge with you.
|
||||
|
||||
* Look at the diffs. `git diff` will show a three-way diff,
|
||||
highlighting changes from both the `HEAD` and `MERGE_HEAD`
|
||||
versions. `git diff AUTO_MERGE` will show what changes you've
|
||||
made so far to resolve textual conflicts.
|
||||
|
||||
* Look at the diffs from each branch. `git log --merge -p <path>`
|
||||
will show diffs first for the `HEAD` version and then the
|
||||
`MERGE_HEAD` version.
|
||||
|
||||
* Look at the originals. `git show :1:filename` shows the
|
||||
common ancestor, `git show :2:filename` shows the `HEAD`
|
||||
version, and `git show :3:filename` shows the `MERGE_HEAD`
|
||||
version.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
|
|
@ -406,6 +286,7 @@ linkgit:git-reset[1],
|
|||
linkgit:git-diff[1], linkgit:git-ls-files[1],
|
||||
linkgit:git-add[1], linkgit:git-rm[1],
|
||||
linkgit:git-mergetool[1]
|
||||
linkgit:gitmergeconflicts[7]
|
||||
|
||||
GIT
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue