2

I work in a team where frontend dev and backend dev work together on single feature branches. Currently we do not know how to resolve merge conflict when both sides, front and back, produces merge conflict.

Assume we have 3 files in repo:

index.html
frontend_code.js
backend_code.py

Both frontend_code.js and backend_code.py are in conflict with master (for example another dev team merged something to master).

We want to keep both: new feature code and the code that was already merged to master. And here is a problem. Backend dev knows only how to fix backend_code.py and frontend dev knows how deal with frontend_code.js and to resolve conflict you have to deal with whole codebase.

Is there a option to resolve conflict by file/folder so every dev could do this for themselves?

Kronossos
  • 31
  • 5

2 Answers2

2

You have an organizational problem, and you're trying to solve it with technology. An analogy, because I hate poor analogies:

How can I let two of my employees use the same hammer at the same time?

Now someone could say:

Hire a left-handed person and a right-handed person, put the former to the right of the latter, and now they can hold it and hammer together.

See for example git partial merge, not whole branch, Resolve merge conflict only for some files and commit to branch for other teams to resolve theirs.

But it's missing the point that you should just buy a second hammer. The same goes for your scenario: people with different disciplines working on the same feature branch are going to run into conflicts, especially when merging other branches into theirs, because they don't know what the code is supposed to look like after merging.

So I'd suggest first and foremost to go back to the planning stage, and make sure the back-end team finishes their features before the front-end team is supposed to consume their work. If that's hard to do, which it usually is in shops that build web applications, then I'd suggest splitting your feature branches again: feature/foo/front-end, feature/foo/back-end. Then both can merge each other's changes when they're done, and solve conflicts they know how to solve.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
0

We had a similar problem with a large Repo used by multiple Teams where Auto merge PRs are created across branches to keep code up-to-date.

Researched a lot trying to fix only those conflicts belonging to our team and leave the rest to respective teams. Unfortunately, you can't half fix a merge conflict, git merge conflict --abort resets all the changes.

One approach might be is to pull often and stash changes before attempting merge.

And if still you get conflicts, begin the merge, fix your part and invite the other team to a call or ping and ask what changes need to be retained.

user8455636
  • 1
  • 2