7

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.

8
  • 4
    if there is a conflict then you must have changed the files... so you must know what they are doing?
    – Ewan
    Mar 15 at 14:34
  • 6
    so if the branch you merged to your branch is merged to dev, the conflicts should disappear?
    – Ewan
    Mar 15 at 16:45
  • 3
    This sort of thing is why I prefer rebase rather than merge flows.
    – pjc50
    Mar 15 at 17:03
  • 7
    rebase is just merge with more potential to screw up
    – Ewan
    Mar 15 at 17:22
  • 7
    Ok, everyone telling this person "you screwed up" is not helping. Branching for a larger feature is not some alien concept that we haven't dealt with before. Since time machines do not exist, let's focus on how this person can move forward. Mar 15 at 18:47

4 Answers 4

4

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.

3
  • I really like this approach! Mar 16 at 12:33
  • "Adhering to [Git Flow] would have prevented the current conflict." - not sure why you think Git Flow prevents conflicts? What the OP does sounds exactly like Git Flow, with multiple long-running feature branches, which have a higher likelihood of conflicting with each other the larger they are.
    – Bergi
    Mar 17 at 10:26
  • @Bergi my team used git flow for years and we avoided conflicts by always going through PR to an integration branch, preventing the trouble that cropped up here. We wound up discarding the process as "too much ceremony", with high training costs for new hires. Maybe one could do git flow with individual developers accepting unreviewed merges from one another, and it all works perfectly? But I've never seen it.
    – J_H
    Mar 17 at 14:44
4

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.

4

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.

2
  • 2
    "Fortunately, we have a lot of real-time collaborative tools to perform pair programming or peer review." -- this is the answer here. You cannot collaborate without collaborating. The OP needs the help of the other developers. They all need the proper tools to collaborate. Plain and simple. Mar 17 at 12:27
  • 1
    Besides tools, I wanted to stress the idea of programming as a team activity. We don't programme isolated and decontextualized chunks of code that someone else will glue and assemble. Programmers working on the same code base are working on the same goal and purpose, just happens they do it from different angles.
    – Laiv
    Mar 17 at 15:26
3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.