How to collaboratively resolve conflicts in Git?

Question

We are working on a big feature, because we don't know how to make it any smaller. I got to a point, when I need to merge my changes from our feature branch into develop branch (we're using Git Flow), but there are many conflicts, some of them are in the GUI which I have no idea what is doing, some of them are in code written by someone else. I'm trying to merge the develop into my feature branch to resolve the conflicts, but I want the guys who know their code to resolve their conflicts.

Is it possible to collaboratively resolve the conflicts in other way than sitting at one computer doing it together? My colleagues are 1200km far away, so it's not very convenient to meet at one place.

Answer 1

many conflicts

Whoops. You messed up. I'm so sorry for you. Live and learn. Perhaps next time y'all will do better.

Ground rules: You do have automated tests, right? And they run Green. Good, we can proceed.

During sprint planning you should have coordinated the efforts of various developers. This is the principle means of avoiding conflicts. It takes practice, and by now you've had more practice than before, you've seen places where things can go south.

Then during PR the affected people should have had an opportunity to notice potential conflicts and coordinate. But we're past that now, as your buddy has merged to develop and you're trying to close out the sprint.

Imagine you spent a few days writing source code or a PPT deck, and then your laptop caught fire and you bought a new one. Is the work "lost"? Yes. Would it take you days to reproduce similar work? No, because you learned things during those days.

Now, let's close out that sprint. Preserve your current branch. Definitely push it so the git server has a copy. Often I will put a copy in /tmp. Now, pretend your laptop caught fire. Checkout a fresh develop that has your colleague's code in it. Invent a new branch name and make a brand new feature branch. Verify that tests run Green. Now, you need to write your feature on top of this existing code. Fortunately, you already know how to do this. Plus, you can refer to stored code, and copy-n-paste it into this new branch. Produce some code, and verify it runs Green. Do a final WIP commit, and push branch to server.

Do one last $ git pull develop, just to verify you're still in sync. Good! Now submit a PR to your colleagues, await approval, and do a clean merge in the usual way. Done.

(we're using Git Flow)

Ummm, with all due respect, no, you're not. Adhering to that approach would have prevented the current conflict.

---

Going forward, prefer to integrate fresh code from colleagues via the integration branch. The name of the integration branch is usually develop, or in some projects main. Merge edits up to it, and pull edits down from it.

And do verify that tests in CI/CD run Green before attempting such steps.

Answer 2

You messed up.

You branched from the development branch, and made changes in your own branch named "branch". Someone else branched from the development branch, made changes in their branch, and merged into develop. And if you try to merge into develop, you get conflicts.

You need a branch that can be merged into develop without conflicts. Here's what you do: You create branch2 from develop and get yourself a good three-way merge tool. Then you test if branch2 actually works. If not you complain to the developer who merged into develop and fix it.

Then you start moving a complete set of changes from "branch" into "branch2". Adapt the changes when necessary because of the changed UI. "Complete" means these changes might not be enough on their own to do something useful, but consistent and not harmful. At the same time you move UI changes into your old "branch", so you have two branches now that have become more similar. You test branch2 and make sure it works.

And then you repeat, until all changes are moved from branch to branch2 or vice versa. And eventually they are identical, branch2 works, and it can be merged into develop because it is just develop + changes.

Answer 3

I'm trying to merge the develop into my feature branch to resolve the conflicts, but I want the guys who know their code to resolve their conflicts.

This is not how it works. Coding is a shared responsibility.

You also contributed to the conflict by changing someone else's files, so the responsibility is yours as well.

Others don't know what's going on in your branch and why you have changed "their" files, so they cannot solve (alone) conflicts for you. Even if you force'em to do it, they will need context, hence your help.

The collaborative way to resolve conflicts starts by minimizing the chances for them to happen.

For example

• Agree on a common code style/format
• Split features into small tasks to favour smaller commits and frequent PR/MR
• Do a holistic assignment of tasks instead of you frontend, me backend
• Reduce the blast radius of changes by design, not by counting how many changed files can go in the same commit.
• Do merge into your local branch more often to handle conflicts and test failures ASAP. Don't wait weeks or months.
• Merge more often to develop
• Ask your coworkers about the changes you have merged into your local branch if you find conflicts hard to solve. Ask for context, not arguments.
• Communicate with coworkers on a daily basis. Be interested in what they do. This will allow you to anticipate possible conflicts and allocate code on purpose for that to happen in a graceful way.

My colleagues are 1200km

It's the XXI century. Fortunately, we have a lot of real-time collaborative tools to perform pair programming or peer review. Even some platforms offer Virtual IDE on the cloud.

Spend time wisely by looking for solutions, not excuses.

Answer 4

OK here is how to collaboratively resolve the merge conflicts, without communication.

Your situation

master
- dev
-- feature A (your feature)
-- B (colleague 1's feature)
-- C (colleague 2's feature)

You deviated from git flow by merging B into A.

then C was merged into dev

now you want to merge A+B into dev, but the changes from B conflict with C

The solution is simple. If colleague 1 merges B into dev, they will have to resolve the merge conflicts between C and B. These are the conflicts you don't understand.

once that has happened, your changes from B in A should no longer cause conflicts. You will be left with only the conflicts from A (which you do understand)

Depending on how crazy the B vs C conflicts are you might have to do some tweaks. But you will at least be able to see what changes colleague one made to B when they merged.