Personally, I believe merging 'master' to your feature branch is the wrong model... what one should do is create a new branch from master and merge the old branch into it.
Why? Merging master into the feature branch is done so that you can test the conflict resolution in the branch before inflicting it on everyone. It’s also done on a regular basis in longer running feature branches to prevent large conflicts from accumulating- you can merge master into your branch multiple times to stay current with master before ever merging back into master. I’m not sure why parent says this causes them to lose track of which changes happened in which branch. The history does get a bit more complex at a glance, but for any given commit, it’s easy to pinpoint their origin if using only merge commits. It only gets harder if you accidentally rebase someone else’s commits along the way. For smaller feature branches and smaller projects, it’s okay to merge branches into master, but for large branches, large projects, large teams, and teams that care about testing, merging master into feature branches is a best practice. What makes you consider it ‘wrong’?
A merge commit is just a commit with two parents. You're not affecting the master branch at all when you "merge in master", you're just creating a new commit where the first parent is your branch, and the second parent is the master branch.
If you do things the way you're suggesting, you'll make it really hard to tell what commits were made on your branch. Git clients tend to assume the first parent is the branch you care about.
