Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
I have a similar question, but with different requirements, so I added another question. programmers.stackexchange.com/questions/109229/… –  Roger Wernersson Sep 19 '11 at 8:10
add comment

5 Answers

up vote 9 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
+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 '11 at 12:21
    
@MarkJ: A manager that is an obstacle to merge conflicts is not a bad thing. Excellent point. –  S.Lott Sep 16 '11 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. –  Gary Buyn Sep 16 '11 at 20:31
add comment

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.

share|improve this answer
add comment

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 )))

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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