There are two common workflows - 'merge based workflow' and 'rebase workflow'.
In the former, you use git merge to merge in changes which creates merge commits (commits with multiple parents). People who like preserving history tend to prefer merge based workflow. I personally like to use git merge --no-ff --no-commit, which allows git to do what it can to automatically make the merge but then lets me inspect the files before concluding the merge - I do this to ensure that every commit compiles. There are cases where git can automatically merge two compiling commits into one that doesn't compile (e.g. one branch removed an unused variable and the other branch added code that uses that variable - no conflict because different lines were changed, and each branch compiles, but the automatic merge does not compile).
The latter workflow is typically used by people who like a clean commit graph. Generally this is because they use tools that visually represent the commit graph to them and merge-based workflows are confusing to look at. So, instead of merging, they use git rebase and/or git cherry-pick to apply the commits onto the master branch so every commit only has a single parent. This has the effect of rewriting history, and thus changing the commit hashes.
The two workflows can be mixed but the people who use them will generally disagree about which is 'better' :)