14

I got involved in a discussion recently on how to handle refactoring in general (which is an interesting topic in itself). Eventually the following question was brought up:

How does one handle merge conflicts that occured due to that someone did a refactoring of a part of the code, while someone else was working on a feature for the same piece of code?

Basically, I have no idea how to deal with this in an efficient manner. Are there any best practices that one should follow regarding this? Is there any difference on how one should handle this for a system with tons of legacy code?

Improve this question
1

5 Answers 5

Reset to default
10

Good question. The best strategy I can think of is:

Prevention

A combination of continuous integration and making small refactorings often (instead of occasional large refactorings) will go a long way to minimizing the cost and frequency of such conflicts.

Improve this answer
3

I think to answer your question, first we have to see why conflicts happen, and what is the true meaning and process of merging?

Conflicts occur only when two or more developers are working on the same file at the same time and then they both try to check in. The first developer won't get any conflict, of course. But the second (third, fourth, and so on) would get conflicts. Why, because (s)he has some code which is partially or entirely different from existing code on the server.

This in nature means that the second developer has something in mind different than first developer. This difference can vary from styling, like using new UserManager().GetUserName() instead of UserManager userManager = new UserManager(); userManager.GetUserName(); up to the level you mentioned, which means that both developers had different ideas of how to refactor the code to improve it.

Merging, on the other hand, doesn't mean that developers can check-in their code without considering conflicts. They should and must address those conflicts. If conflicts are not important, then they may check-in and override previous code. But when they see something entirely different, they should call the previous developer, and talk to him, so that they can both get coordinated together to check-in the best solution.

For example, if you ask two developers to improve online-payment library, and their work overlap, this means that at least on some places, there are 2 different solutions. So, one of those solutions should be talked about and be accepted, thus checked-in, as the better solution.

I don't agree on preventing these circumstances, as we should tend to be more real than theoretical. Sometimes a guy is really good at CSS, while another is really good at ASP.NET Markup. But their work may conflict when they should both work on login page to make it work. I mean, if we think real (not ideal), we can see that many times this phenomenon (conflict) happens.

Another point I just wanted to mention, is to use tools to help you in your check-in process. These tools usually visualize the difference of server code and developer code, and helps a lot in determining which part should be checked-in.

Improve this answer
3

If there's no active management of tasks, you have conflicts.

If, however, you have a daily stand up meeting or a manager, you cannot possibly have this problem.

Either talk (via a daily stand up) or talk to a manager.

This is trivially prevented by talking.

Improve this answer
3
  • +1. Some developers see managers as an obstacle. But managers really exist to enable other people to work, and this is an excellent example of a problem they can help with.
    – MarkJ
    Sep 16, 2011 at 12:21
  • @MarkJ: A manager that is an obstacle to merge conflicts is not a bad thing. Excellent point.
    – S.Lott
    Sep 16, 2011 at 12:49
  • +1 I was just about to add something like this to my answer but you nailed it. If you're using a conflict to let you know someone else was working in the same area, you're going to find out very late in the game and then have to deal with it. Task management and communication can enable developers working in the same area to work together from the beginning.
    – Gyan aka Gary Buyn
    Sep 16, 2011 at 20:31
1

Have a separate common branch for developing a certain feature, merge/pull/push often - that's it.

And communicate. Speak with other developers about code even when launching. Even when coding )))

Improve this answer
1

Make sure that the merge is as simple as possible. Refactoring is usually a rather mechanical process which changes many existing lines: Move variable declarations, whitespace changes, formatting, sequence of operations. Feature creation is usually a much more creative venture, often resulting in new code plus a few minor tweaks to the existing code. Now if the developer doing the refactoring records the steps (for example as regular expressions), it can be much easier to apply these to the code with the extra functionality rather than the other way round. Based on this, I'd say that as a general rule you should apply the most complex change first, followed by progressively simpler changes.

Improve this answer

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.