1 <?xml version="1.0" encoding="UTF-8"?>
\r
2 <!DOCTYPE sect1 SYSTEM "../../../dtd/dblite.dtd">
\r
3 <sect1 id="tsvn-dug-conflicts">
\r
4 <?dbhh topicname="HIDD_RESOLVE"?>
\r
5 <title>Resolving Conflicts</title>
\r
7 <primary>conflict</primary>
\r
10 <primary>resolve</primary>
\r
13 Once in a while, you will get a <emphasis>conflict</emphasis> when
\r
14 you update your files from the repository. A conflict
\r
15 occurs when two or more developers have changed the same
\r
16 few lines of a file. As Git knows nothing of your
\r
17 project, it leaves resolving the conflicts to the developers.
\r
18 Whenever a conflict is reported, you should open the file in
\r
19 question, and search for lines starting with the string
\r
20 <literal><<<<<<<</literal>.
\r
21 The conflicting area is marked like this:
\r
23 <<<<<<< filename
\r
26 code merged from repository
\r
27 >>>>>>> revision
\r
30 Also, for every conflicted file Git places three
\r
31 additional files in your directory:
\r
34 <term>filename.ext.mine</term>
\r
37 This is your file as it existed in your
\r
38 working copy before you updated your working copy
\r
39 - that is, without conflict markers. This file has
\r
40 your latest changes in it and nothing else.
\r
45 <term>filename.ext.rOLDREV</term>
\r
48 This is the file that was the BASE
\r
49 revision before you updated your working copy. That is,
\r
50 it the file that you checked out before you made
\r
56 <term>filename.ext.rNEWREV</term>
\r
59 This is the file that your Git
\r
60 client just received from the server when you updated
\r
61 your working copy. This file corresponds to the HEAD
\r
62 revision of the repository.
\r
70 You can launch an external merge tool / conflict
\r
73 <guimenu>TortoiseGit</guimenu>
\r
74 <guimenuitem>Edit Conflicts</guimenuitem>
\r
76 or you can use any other editor to manually
\r
77 resolve the conflict. You should decide what the code
\r
78 should look like, do the necessary changes and save the file.
\r
81 Afterwards execute the command
\r
83 <guimenu>TortoiseGit</guimenu>
\r
84 <guimenuitem>Resolved</guimenuitem>
\r
86 and commit your modifications to the repository.
\r
87 Please note that the Resolve command does not really
\r
88 resolve the conflict.
\r
91 <filename>filename.ext.mine</filename> and
\r
92 <filename>filename.ext.r*</filename> files,
\r
94 I use "git add" to mark file status as resolved
\r
95 to allow you to commit your changes.
\r
98 If you have conflicts with binary files, Git does
\r
99 not attempt to merge the files itself. The local file remains
\r
100 unchanged (exactly as you last changed it) and you have
\r
101 <filename>filename.ext.r*</filename> files.
\r
102 If you want to discard your changes and keep the repository
\r
103 version, just use the Revert command. If you want to keep
\r
104 your version and overwrite the repository version, use the
\r
105 Resolved command, then commit your version.
\r
108 You can use the Resolved command for multiple files
\r
109 if you right click on the parent folder and select
\r
111 <guimenu>TortoiseGit</guimenu>
\r
112 <guimenuitem>Resolved...</guimenuitem>
\r
114 This will bring up a dialog listing all conflicted files
\r
115 in that folder, and you can select which ones to mark
\r