How can I accept all remote files in a specific folder during a git merge?

问题

We're using posh-git on Windows Powershell for source control.

We're in the unenviable position of storing some of our built assemblies in our git repo. I know all the sermons on why you shouldn't do that, but we have to live with it for now. Thankfully they are in a separate solution, but sometimes two people work on that solution in their own branch simultaneously, and the last one in gets to take the merge conflict. The process, of course, looks something like this:

Person A lands their changes on develop.
Person B merges those changes, which include both assemblies and update source code.
Person B resolves conflicts, as has to confirm which version of each assembly they want to keep. This is annoying and time-consuming, and also unnecessary since Person B will rebuild the assembly after merging the source code anyway.
Person B rebuilds the assemblies and makes a new commit to finish the merge.

The assemblies are in a folder in our Repo: /Source/Foundation Assemblies/

Person B cannot just take all changes from the remote, since their branch may have conflicting changes, but it would be helpful to just "take theirs" or "take mine" for the /Source/Foundation Assemblies/ folder only. Is this something that can be done with git?

A command line example would be helpful. Normally, the merge would just be:

git merge develop

I was thinking it might be possible to .gitignore the /Source/Foundation Assemblies/ folder, and then remove it from the .gitignore after the merge, but that is three steps. If we could do it in one from the command line, that would be GREAT!!!

Any help appreciated!

回答1:

The "right" way in your case is to rebuild the assemblies before committing the merge. I don't see why you would not do this. The steps as follows should work:

resolve and git add all conflicted sources. Then whatever happens during merge should not affect what you commit.
remove the conflicted assembly files. No need to do anything with their git information, just remove the files
build the assemblies.
git add the ready assemblies.
Then commit. What you get is merge which includes both local and remote changes.

EDIT: try this:

git rm --force -r <dirname>
run your mergetool, now it should now mention the binary files (kdiff3 did not)
build assemblies
git add <dirname>
commit

I tried this bash script to reproduce you case as I understand it.

回答2:

You can do git merge develop -X theirs, and all conflicts will take the remote branch's copies.

Edit: Looking back over your question I see that you only want to take "theirs" for a particular subfolder. In that case, after git merge develop, do git checkout --theirs /Source/Foundation Assemblies/. This will replace the contents of that folder with "theirs". Then just git add /Source/Foundation Assemblies/ and you are good to go.

回答3:

You have several merge strategies which you can use:

resolve

This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.

recursive

This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.

The 'recursive' strategy can take the following options:

ours

This option forces conflicting hunks to be auto-resolved cleanly by favoring 'our' version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.

This should not be confused with the 'ours' merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring 'our' history contains all that happened in it.