How to handle Git merge conflicts in Git Pull

After the project branch from master, my team and I works on the dev branch to add new features. As multiple people are committing changes on same files, merge conflicts constantly appears.

Is there a good way to handle merge conflicts when trying to pull and commit new changes to dev branch keeping up to date with my team's commits? How can I visualize differences between the latest commit on dev branch with my local changes.

Solution

I'll suppose you share a common remote repository called origin with your teammates, because this is a very common situation and the default name for such a remote.

You can see the difference between the dev branch on origin and your current local branch by doing git diff origin/dev HEAD (HEAD is an alias for the latest commit in your current branch)

About the merging strategy, I don't think there is one truth, you'll get opinionated answers. The only thing I suppose anyone could agree with is that you should synchronize your work with the common branch as often as possible. The longer you diverge, the more conflicts you'll get and the harder they will be to fix (because you and your teammate will have time to forget what the conflicting code was doing).

Personal answer : my team is using a rebase strategy. Once in a while, we will perform a git rebase origin/dev from our current working branch. What this does is it modifies the history of your branch to insert everything from origin/dev BEFORE any of your commits. Then, when we have finished our work, we rebase one last time (to make sure we included the lastest dev branch code in ours), and finally we merge the whole thing back to the common branch :

git checkout dev
git pull origin dev
git merge myBranch
git push origin dev

Pros :

You solve conflicts one commit at a time, it's less scary and easier that way
You never have to produce a merge commit (these tend to be a major cause of future conflicts in my experience)
All your commits from a single piece of work remain grouped in the history
You resolve conflicts in your local branch, not in the common branch. It's safer is you mess up.
Merging your work in the common branch is a piece of cake, because it is always a fast-forward (again, no merge commit) and because all conflicts have already been resolved.

Cons :

A huge red flag : you NEVER want to rebase a branch that is shared in your common repository. If you follow the procedure above, rebasing is always done in your personal branch that you don't share with others. That is fine. But if you accidentally rebase your dev branch, do not push it ! Rebasing rewrites history, you may erase your teammates work by doing so.
Rebasing takes more time than merging because you fix conflicts one commit at a time and may on occasion have to resolve the same conflict multiple times.