问题
There is a project using github repositories. When there are conflicts to be resoled before merging pull request some 90% of conflict cases concern just one CHANGELOG file containing list of completed tickets, sth like:
## current
<<<<<<< HEAD
ISSUE-128 done some 128
ISSUE-131 done some 131
=======
ISSUE-125 done some 125
>>>>>>> ISSUE-125
ISSUE-126 done some 126
ISSUE-120 done some 126
ISSUE-123 done some 126
I wonder if there is a way to automate merge of this particular file (possibly by providing some configuration using i.e. gitignore format) with a simple rule to just accept the changes from both sides (as for the order its enough that the changes will be just next to each other, knowing how could be possible to control the order is secondary yet interesting). Additional rule could be to verify if there is always just one addition on each side and only then proceed with the automatic merge.
Ideally would be to have such configuration on github yet even local git solution would be helpful.
回答1:
[Answer, slightly modified from comments.]
What you want here is usually called union merge, and this is actually built in to Git. It rarely does the right thing, but for this particular case, union merge is actually probably correct. You can set union merge for a particular file name using .gitattributes. See git merge, keep both for more about this.
Actually the only thing I'm still somehow worry about is that for a "more complex" conflicts I'd rather see that there is conflict to merge
Right: the main problem with union merge, I think, is that it always succeeds, even if the merge result is nonsensical. You need to remember that it is set up this way, and be careful to check the merge result every time.
(Personally I'd be happier with all of this if Git had it split out into a separate "resolve" command one could invoke on each file. I think the git merge-file command is, in fact, mostly what one wants here, except that it is a pain to use. With a more useable interface, instead of -X ours and -s ours and -X theirs and so on, and various merge drivers in .gitattributes, we could just let the merge conflicts happen, inspect them, decide which side(s) to keep if that suffices, and go with that. Of course if one goes much further down this road, one ends up with a GUI merge tool...)
回答2:
That problem occurs frequently; aside from Changelog style files, it also happens if you have, for example, source files and add new stuff - most times you add new methods or whatever at some canonical place (like near the end of the file), and upon merge they all show up as conflict, every time.
Short answer: git cannot help you here, nor can any other automatic merge tool, short of true artifical intelligence. There is the union driver mentioned elsewhere, but, quite frankly, this would be much to dangerous for me, even for a Changelog file. You could do it with a custom merge driver which understands your Changelog format, but the effort will likely put you off of that idea (if so, the gitattributes manpage has more information for you).
Side answer / tip: I had some success with having comments like this in my source files:
def lastmethodinclass
...
end
## placeholder 1 ##
## placeholder 2 ##
## placeholder 3 ##
end # class
Then, in a first branch, I put a new method behind "placeholder 1". If I later remember, in another branch, that I have "used up" the first placeholder, I put my next method after the second placeholder, and so forth.
This is still very awkward, but it works to avoid those pesky conflicts. From time to time, I clean out old placeholders that accumulate after merges and stuff them back where they belong.
Useless when coding with others, yup.
来源：https://stackoverflow.com/questions/38502458/resolve-git-conflicts-for-particular-files-by-automatic-merge-all-changes