1. You (among with most of such recipesʼ authors) have omitted one principal thing: in a complex case, to understand how a conflict should be resolved, you might see an original base of each conflicting chunk. To make it visible in conflicts, use setting: git config merge.conflictStyle diff3 (you may add --global for global setting).
This will add a new section, like in the following example:
original:
1
2
3
version1:
one
2
3
version2:
1
two
3
After merge attempt:
<<<<<<< HEAD
one
2
||||||| b58938fa
1
2
=======
1
two
>>>>>>> two
You see new section after |||||||| - this is the common base.
Not only a human gets aid from it - this is crucial for automated merge tools.
2. Next: use automated merge tools. There are lots of them: kdiff3, vimdiff... They have two merits: 1) they are deliberately smarter than default git logic and may resolve conflicts that git retains unresolved; 2) they provide visual interface to merge.
For a command in git, this is git mergetool (shall be configured, what tool to run).
3. Use aid to understand what change is applied now to make the conflict. Depending on operation, this could be git status plus git show for specified commit id (shows the applied patch - typical for rebase), git am --show-current-patch (I use alias git amsh for it; used for cherry-pick as well).
4. Notice that sometimes git misdetects what chunks to compare. You might need editor to relocate code blocks to realize the proper relation between chunks. I usually experienced this in case of sequence of small methods when something is inserted inside the sequence.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few principal notes.
1. You (among with most of such recipesʼ authors) have omitted one principal thing: in a complex case, to understand how a conflict should be resolved, you might see an original base of each conflicting chunk. To make it visible in conflicts, use setting:
git config merge.conflictStyle diff3
(you may add--global
for global setting).This will add a new section, like in the following example:
original:
version1:
version2:
After merge attempt:
You see new section after
||||||||
- this is the common base.Not only a human gets aid from it - this is crucial for automated merge tools.
2. Next: use automated merge tools. There are lots of them: kdiff3, vimdiff... They have two merits: 1) they are deliberately smarter than default git logic and may resolve conflicts that git retains unresolved; 2) they provide visual interface to merge.
For a command in git, this is
git mergetool
(shall be configured, what tool to run).3. Use aid to understand what change is applied now to make the conflict. Depending on operation, this could be
git status
plusgit show
for specified commit id (shows the applied patch - typical for rebase),git am --show-current-patch
(I use aliasgit amsh
for it; used for cherry-pick as well).4. Notice that sometimes git misdetects what chunks to compare. You might need editor to relocate code blocks to realize the proper relation between chunks. I usually experienced this in case of sequence of small methods when something is inserted inside the sequence.