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