As Sandeep Panda and Cho, Yongjoon have said, it's best to avoid merge conflicts if possible. One of the ways of doing that is to have not have feature branches and work on the dev branch directly. This ensures that all developers are basically pushing to the dev branch every day or at max every 2 days. If the feature is bigger than a 2 day coding effort, it's a sign that it must be broken down into smaller elements that can be continuously merged in. This is an extreme example of short-lived feature branches.

I think the advent of Git-Flow was the root cause of a lot of unnecessary merge conflicts.

Now, if you already have merge conflicts, more often than not, a decent GUI for Git will have you covered. Personally, I use Gitlab's code review tool to view the diff and resolve conflicts. Else, Atom's Git integration is also pretty decent allowing you to pick the changes that you'd like to commit.

try VScode

Don't rely on version control to handle it. Automation in general is replacing JUST TALKING TO THE OTHER PEOPLE WORKING ON YOUR PROJECT and is one of the FASTEST ways to suck the quality -- and humanity -- out of the process.

There is an over-reliance on tools and an under-reliance on communication that is gutting the quality and sustainability of software projects of all sizes. Pick up the phone or GOD FORBID get off your arse and walk across the hall and TALK to the other people working on it. Establish code "provinces" and delegation of tasks instead of blindly hoping that multiple people working on the SAME PIECE OF CODE is going to somehow magically work!

In that way, modularization and proper management can go a lot farther than any stupid tool can. Divvy up the tasks, give each member of the project subsections that speak to their specialties and skillsets, and if they need to tread the line out of their assigned zone for something, ACTUALLY HAVE THEM TALK TO EACH-OTHER!!!

... and yes that means more work for the person in charge, that's why it's called work and not "happy happy fun sexy time"

Not like this, tell ya that much.

I feel that this is a simple and solid approach that's often overlooked:

1. Commit your code when anything is worth saving.
2. Do not push it yet. Instead, 'git pull origin master'.
3. If there is an existing conflict, it should be minor. Resolve it.
4. Then, commit with -m 'Resolved merge conflict'.
5. Then - again - 'git pull origin master' to guarantee you have the latest.
6. Rinse, repeat steps 3-5 until you get a clean pull.
7. Push your branch.

No matter how long the life of your branch is, it's now being bookmarked with local commits, and then merged with origin/master to avoid a future conflict (aka trainwreck.)

In my experience, Atom (Merge Conflict/Split Diff) and VS Code (GitLens) have nice packages/extensions for Git in general. I would always advise learning git via CLI vs a GUI, since pressing a button is way different from typing commands with the intention of accomplishing something specific.

I used to be scared of conflicts when I was a little boy; LOL, by that I mean when I started my career, but then you just get used to it.

You just simply pull the code from the main branch/fork, and resolve it step by step by reading the code. You know what changes you made and you know what changes the other guy made. If you have any doubts, just pull the other guy in and talk to him and have it resolved, like @sandeep said. :)

I agree with Cho, Yongjoon. It's best to avoid introducing conflicts in the first place. However, that's not possible always. For simple conflicts, the GUI based diff is sufficient. For more complex cases, I sit down with the other developer and try to fix the conflict. This is just to make sure I don't accidentally delete anything.

With our toolset and using VSCode we get the option of displaying conflicting code blocks next to one another and clicking to choose which version to go with. We're quite a small team (of eight) so this isn't usually too much of a problem.

First of all, not making merge conflicts or reducing the size of them are the best way. So don't make 'long-running branches' which is very apart from the master branch.

Our team frequently rebase the feature branch to the master branch.

In the recent article from the React team, they explained 'feature flag' approach against 'long-running branches'.

Additionally, the latest atom has great GUI to show and resolve merge conflicts. I believe there's similar features in other editors, too. For the complex merge conflict, however, direct communication with other developers is much important than a tool.