Weird git behavior when merging

Question

git

The approximate history of development was as follows (I’ll clarify, I didn’t develop it - I just helped to “merge”)

The person worked in his branch, let’s call it feature , deviated from master even under the king of peas. At some point it took updates from master via merge. Then he continued to work in his branch. After some short time, the development of the feature ended, and the person decided to pour the changes into master . I decided to pour in one commit, i.e. with a key --squash. Naturally, conflicts arose. So, a number of problems arose:

• There were conflicts in files that were not even edited in the feature branch (with the exception of the commit generated by merge`m). And it seems to confuse the developer of the feature branch . Doesn't git respect previous merge?
• Okay, those files that the developer did not pick in his feature branch , they decided to take completely from the master version (that is, with the command git checkout --ours -- some_fileswhile in master). And here's the strangest thing, after this command nothing happens to the files. Why is that?

Git gurus come to the rescue. I understand that I do not understand something, please explain.

Answer 1

Probably, as usual, empty lines, spaces and tabs have changed.

Answer 2

If you want to do it in one commit, why not merge feature and master with the --no-commit option? After checking and resolving conflicts, make a commit in the master and upload it to the server, and delete the feature branch (as far as I understand, the history in it is not important).

Answer 3

Probably not relevant anymore, but since there is a question in the toaster and someone may stumble upon it, I think my answer will not be superfluous.
I can't say exactly how to make git take into account the fact that master is merged into feature . But this particular problem could be solved with the help of rebase.
Let's designate the following commits with tags:
beforeMerge1M - commit in the master branch just before the commit of the first merge.
beforeMerge1F - commit in the future branch just before the commit of the first merge.
First you need to replace the first merge with rebase.
To do this, we rebase the sequence of commits from the beginning of the future branch before the master is merged into it to the master commit that precedes the merging:

git checkout beforeMerge1F
git branch tmpFeature
git rebase beforeMerge1M

Thus, the head of the tmpFeature branch will have exactly the same state as the result of the first merge.
Now rebase the rest of the branch to this commit:

git checkout feature
git rebase tmpFeature

Now the state of the feature branch remains the same, but the history has changed - there is no merge commit in it and it branches from the master after the beforeMerge1M commit .
You can do the merge in master , which was planned, but it may make sense to rebase it again on the master in order to resolve the conflicts that arise in the process, if there are any, and then merge without problems.

git rebase master
git checkout master
git merge feature --squash

ps. All this is speculative reasoning and somewhere I could be mistaken, write to me in this case, I will help you figure it out.