Daniel,
----- Original Message -----
From: "Konstantin Khomoutov" <[email protected]>
To: <[email protected]>
Cc: "Daniel PRESA" <[email protected]>
Sent: Thursday, November 24, 2016 8:42 AM
Subject: Re: [git-users] Help to understand git merge conflicts
On Wed, 23 Nov 2016 11:43:13 -0800 (PST)
Daniel PRESA <[email protected]> wrote:
So here is the thing, i just don't get the git merge conflict and how
to resolve them,
especially when i already tried to resolve the conflict and finished
to have half my changes merged, the other all ignored
and files someone have modified in me personnar repository i dont
even know how.
^^^ This smells like you're actually attempting your merge in a wrong
way. With zero details to consider, it's impossible to provide any
constructive feedback, but if your repository is really personal,
there's no way someone could have committed any changes into it.
It's rather more likely that you have accidently messed something up
like force-pushing something into a repository's branch, which you're
now attempting to merge with some other line of history.
I tried to find documentation about how to resolve this but i don't
find anything i can understand, it's really depressing.
That's surprising. Resolving merge conflicts is a rather
straightforward operation.
There is a one step that is commonly missed (by new users).
Once the offending conflict marjers have been found, and the conflict
resolved by choosing which parts to keep/edit, and removing the markers, the
users do need to:
* first save the fixed up changes,
* secondly (usually missed), 'git add <file>' the file which is now fixed,
so that the staging area (Git's index) will now know that the conflict's fix
is complete.
* use the appropriate --continue step to complete the merge and its commit.
Without the git add step the user will continue to get those frustrating 'I
don't know what's wrong, I've already fixed the file' messages that say
there is still something to 'fix'.
Basically running `git status` makes Git
1) List all the files with merge conflicts.
2) Explain what to do about each of them.
Merge conflicts for particular files can be of three types:
1) Both "we" (locally) and "they" (the changes we're trying to merge)
changed the file's contents, and these changes overlap.
In this case, for each text region in the file which has overlapping
changes, Git takes both versions of this region and places them both
in place of the original one -- delimited by special strings like
">>>>>", "=====" and "<<<<<".
You're supposed to locate and edit the text in these regions to
make them have the text which should logically contain the reconciled
changes done by "us" and "they".
After that, you `git add` the file's new content so that it's the
part of the next commit.
It's possible to completely ignore the changes done on either side
by overwriting the file in the working tree by either "our" or
"their" version, which is done by
git checkout --ours -- path/to/file
or
git checkout --theirs -- path/to/file
respectively.
You'll still need to `git add` the file afterwards.
2) "We" have deleted a file which "they" have updated in the meantime.
3) "They" have deleted a file which "we" have updated in the meantime,
which is the reverse of (2).
In these cases you have basically two options:
1. Confirm the deletion by using `git rm path/to/file`.
2. Check the version of the file from the appropriate side of the
merge (see above) and decide what to do next.
If you'll decide to keep the file as a result, you'll need to
`git add` its contents as explained above.
--
Philip
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
