2

If there are two unrelated tasks, except that the changes are in the same project, and end up touching at least one of the same classes/methods, how do I manage that?

Two different developers could each pick up one task. Each dev will create a new branch off of Integration, work in it, then need to Merge.

When Merging two branches, most of the time "Take Source Branch" is proper for Up-Merging, and "Take Target Branch" is proper for Back-Merging.

But when Back-Merging, or dual-merging up, there could be conflicts which overwrite the code of the previously merged project if they both changed the same class/method.

One answer is: "So only let one dev work on both tasks sequentially." Except that we're in SCRUM and any dev can pick up any task. We don't want to start assigning.

Another answer is: "Have the devs get together and hash out how to manually merge some stuff." But that's work! Lol. Is there a method I'm missing?

Improve this question
4
  • 3
    Automatic merges can't do everything. Sometimes you just have to go and manually figure out what code belongs.
    – Gort the Robot
    Mar 11, 2014 at 23:20
  • If you have two unrelated tasks that end up changing the same class/method, it might also be a flag that it doesn't follow the single responsibility principle. That's not a hard-and-fast rule, but it's a question worth bearing in mind for the conversation between the devs - is the class/method only responsible for one thing, or is there something from it that needs to be extracted?
    – Myles
    May 17, 2019 at 14:23
  • 1
    @Myles Keen observation, generally speaking. In his talks, Uncle Bob explains SRP as being related to a person. For example, one responsibility is "Accounts Payable", which may be the AP manager... or Technical Reporting, which may be the CTO. Each class is Responsible to that person. So when two different people ask for changes, they shouldn't be affecting the same code, even if the changes seem the same. Those are two different responsibilities. But if the CTO asks for a report to have a new ColumnX, and a new ColumnY, and those two tasks touch the same code, we could reach this situation.
    – Suamere
    May 18, 2019 at 15:14
  • @Suamere - I'm not sure about his talks, but in Clean Code, he describes SRP as meaning "that a class or module should have one, and only one, reason to change [italics in original]." So even within "Accounts Payable", you might have several different functions that each have separate reasons to be changed (e.g. retrieveInvoice, payInvoice), so should be separated. But I agree with the CTO example, though that's the sort of thing that I'd expect to be combined into one request when grooming the backlog.
    – Myles
    May 20, 2019 at 9:52

1 Answer 1

Reset to default
6

You have answered your own question:

Another answer is: "Have the devs get together and hash out how to manually merge some stuff."

That's the only way to resolve this sort of merge conflict. Assuming you don't have rogue developers forking your project, as a team you will have to agree what is the correct result of merging independent work.

There is no magic bullet that will resolve conflicting merges. It's work.

Improve this answer
1
  • Thanks. I think everybody would wish for a magic bullet in a lot of scenarios. I think the Merge tool actually is pretty dam intelligent, but these scenarios are rare (but happen). I think it just needed to be said that the manual-hash was the requirement. I certainly prefer that option over breaking SCRUM.
    – Suamere
    Mar 12, 2014 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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