Workflow strategies for mitigating merge conflicts from topic branches

I'm right on the cusp of selling git to my higher-ups. They're listening to us talk about it, anyway. There's one thing I'm unsure of, and I'd like to see how people deal with this. Basically my question comes from the fundamental understanding that the further apart a pair of branches are allowed to get, the harder they are to merge.

I'm considering proposing this fairly simple workflow: Say I have a master (release) branch, a development branch, and topic branches off of that. Different developers are working on their separate topic branches, pulling and pushing those topic branches to a central repo as often as they feel they have working code. Periodically, when asked to do so by a developer, the maintainer (in our organization that person has the title "technical lead") merges from their feature branch into the development branch, that's put on a staging server and tested, and once the feature test complete, it's merged with master and pushed to production.

Here's my question. Should the devs merge their topic branches periodically? Doing so would ensure that they'll ALL merge back into dev fairly cleanly (or at least catches conflicts early before they can get out of hand). The only thing that I know my manager is going to dislike about tha开发者_运维知识库t is, that's work they have to do to placate their tool, rather than work to deliver code to the project. Thoughts?

We all know that there will be conflicts. The question is really: Who should resolve the conflicts?

It's beneficial if the person closest to the changes that made this conflict happen is the one fixing it. If you let a maintainer handle this (or some other dev) that person might not know what the code is all about. So yes, the devs should probably be responsible for solving merge conflicts. It's a trade off.

Your problem is related to the workflow and that your boss might not like that the technical lead is using his time to solve conflicts. Otherwise this model is not at all a bad one. This role that the technical lead has is often called "integrator" and often involves resolving conflicts and means the integrator needs to know about the code and needs to communicate a lot with the devs (there are also other tools in git that can simplify this scenario).

What you could do, is to let the devs not push and pull their topic branches from the server, but instead keep their topic branches locally and only have e.g. master and develop on the server. If they instead pull from develop, merge their stuff, resolve conflicts locally, and also test locally before they push up develop. That way the devs can instead push up develop and the technical lead can focus on testing develop and do other types of testing like performance testing etc.

However, if you still want the integrator role, there is a tool called git rerere. It enables the integrator to periodically merge branches, solve conflicts, reset to undo the merge and git will automatically record how the conflict was resolved. This is a very good way to minimize the work solving conflicts. You could even automate this with a git hook, e.g. do the merge with a script and just notify the integrator if a conflict has happened.

Some reading:

http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/

Cheers