3

On a web site, a feature branch needs to be merged into master after a couple of weeks of development by both front-end and back-end developers.

The problem is that the back-end developers are unlinkely to be able to solve CSS and template conflicts, and front-end developers can't solve the back-end conflicts. How would you go about solving this?

Some ideas I had:

  • One of the developers solve "their" conflicts locally and hand over patches to the other developer, who'll do the real merge
  • Partial merges somehow, splitting the merge up in several commits
  • Use a different vcs workflow/branching strategy
Jacob Rask
  • 22,804
  • 8
  • 38
  • 36
  • 1
    Get a back-end dev and a front-end dev in the same room (RL or chat), and have them work through the merge together? – Amber May 16 '11 at 07:43
  • I just added the "theirs" merge strategy option, in case of a split merge. See my updated answer. – VonC May 16 '11 at 08:16

2 Answers2

2

One solution would be to split (rebase --interactive) the set of commits into commits with only back-end or front-end files in them, in order for each set of developers to only merge what they need.

That would assume there is no functional dependencies between the two set of codes.

We are working on a joint remote feature branch with a feature that involves both front-end and back-end code changes

If back-end is able to contribute without having to worry about front-end changes, then the merge, after split, is possible.
If not, there would still be potential conflicts when merging in a back-end codebase the set of code regarding front-end. But for that merge, you can use one of the "theirs" strategy when performing the merge.
That would allow back-end developers to get back (and override) all front-end code in their repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

The front-end people should not get back-end conflicts and vice versa. If they do it means the front-end people are changing back-end stuff or the other way around. And if they do get these conflicts, they should also be able to solve them :)

Just think about it. Why would I as a front-end dev get conlicts on my back-end stuff, if I haven't changed anything myself?

rtn
  • 127,556
  • 20
  • 111
  • 121
  • We are working on a joint remote feature branch with a feature that involves both front-end and back-end code changes. – Jacob Rask May 16 '11 at 08:10
  • @Jacob: It doesn't matter if it's a joint remote branch or not. If I haven't changed anything then I shouldn't get conflicts. Period. Just see it as a pull to synchronize your repo. If there are no changes, the pull will go through with no conflicts. The same goes for changes to code that I haven't touched. – rtn May 16 '11 at 08:20
  • I'm sorry if I was unclear, this is merging master into the feature branch to prepare for integration into master. We have development on several tracks, so files will have been changed in master during the time we developed this new feature. – Jacob Rask May 16 '11 at 08:30
  • Aaah I see, so a front-end dude might do the merge from master and get back-end conflicts. Gotcha. – rtn May 16 '11 at 09:05