This question is very similar to this question on merging but with one key difference: the absence of a merge conflict.
So I'm working in a feature branch, commit some changes, and run git merge master. My goal is to update my feature branch with the latest master before I create a PR to merge the branch back into master (that is our chosen workflow, the idea is to resolve issues on feature branches first). I get zero merge conflicts and the merge seems to complete. When I run git log it appears that my feature branch now has the latest commits from master. However, when I run git status a bunch of files that I did not touch (but which appear to have been updated in master) suddenly enter my list of "Changes to committed", and a smattering of them appear as "Changes not staged for commit" and "Untracked files". It is not 1-to-1, in my latest example I had 45 files staged, but only 33 that were unstaged+modified or untracked. I am not committing these files as it does appear the feature branch already has the latest commits from master.
I have to date been dealing with this issue just by running git stash (and clearing my stash periodically). Sometimes I run get reset HEAD to clean it up too. This seems ok since I have the latest commits from master. However, I am not sure if these are desirable actions or the right thing to do. Am I missing a crucial piece of the git merge workflow by ignoring these staged files? What is going on here? What is the name of this behavior? I can't find a reference to this in any of the guides I've read.
One final note that might help. I am on a Mac, but this is a .net + React project, so many devs are on windows. Could this be an issue of autocrlf or other line ending variations between the platforms?
