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. 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.
--
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.
