I'm currently working on a project with a team that's using a git workflow. It's fairly simple, master should be in a deployable state and branches are used to create features and hotfixes. Whenever we have a feature or bugfix completed and tested then we move that over to master as soon as we can. The idea is that branches should be as small as possible to make it easier to merge them back into master. We have a policy that any code pushed to master branch should be in a deployable state and pass the tests.
We have got a situation where one of the developers has done a lot of work (a few months worth) on a single branch and this branch hasn't been merged back into the master yet. There's now a few separate features and a bunch of commits on this branch, essentially this branch really should have been merged back in a few times already but so far hasn't been. Most of the code is in a good state with unit tests that could be merged back into master but the most recent changes should certainly not be as they are not completed and aren't tested.
What is the best way to deal with such a situation where one branch is really far away from the others? What ways can we avoid branches getting a very large number of commits away from master in the future?
Best Answer
Let the developer who went for a couple of months without merging fix it. Maybe they can get one big chunk of code to merge, maybe they can get a bunch of little chunks to merge one at a time. In any case, they should be doing the legwork to fix the problem, since they caused it.
In general, don't worry about it: it's the other developer's problem. If two branches are really too far apart to merge, then they aren't really part of the same project anymore and you have a defacto fork. If it's an open source project, that may not even be a problem.
If this developer is really brilliant, and their code is better/smarter/more important than the rest of the team combined, then it's worth making it your problem instead of theirs. Otherwise, it isn't.
To answer the literal question: the best way to deal with this kind of situation is to not get in that kind of situation.
Make sure everyone notices that the developer who went for months without merging is having to fix the problem they caused. Make sure everyone knows that it's easier to commit to master frequently than infrequently, since fewer changes means fewer opportunities for conflicts.
Make sure that people know that they can pull from master to stay up-to-date with other people's changes.
"If you merge every day, suddenly you never get to the point where you have huge conflicts that are hard to resolve." --Linus Torvalds
That quote is from a talk he gave at Google, here's the transcript, and here's the video.