How to handle dependencies when using git topic branch workflow?

In our project we try to stay close to the "official" git workflow as it is suggested here: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

We use a master and next branch, start our topic branches off from master, regularly do test integration into next, and if a branch is complete, we merge it into master.

Now sometimes it happens, that there's some development on topic-X. A developer creates somefile.c and adds code there that he needs for his topic. After a while another developer works on topic-开发者_如何学PythonY and finds out, that he also needs to create somefile.c and even would need some parts of that file from topic-X - but not the complete file, as it also contains code, which is only related to topic-X. He may also have to add other code to that file.

If topic-X would be complete and merged into master, it would be easy: We could rebase topic-Y to master to make that code available. But what, if both topics are still incomplete?

Because topic-X and topic-Y are really unrelated, except for this minor shared code in somefile.c, how can we avoid to merge them into each other and still provide both developers with the shared parts from somefile.c?

If we create a fresh copy of somefile.c in topic-Y with only the relevant parts, we found that we get merge conflicts later, when we do test integration in next. Is there any alternative?

---

When merging, git will detect whether the changes in the commit have already been applied.

So when you have a commit in topic-x that changes somefile.c which you also want in topic-y, you can cherry-pick that commit in topic-y. (Make it easy on yourself and keep this commit limited to only those things you want shared.)

git checkout topic-y
git cherry-pick topic-x

Later on when you merge topic-x and topic-y, git will see that the patch has already been applied and skip it gracefully.

This is a better choice than rebasing, since rebasing has nasty side effects if the branch has already been made public to multiple developers.

---

It would be best to consolidate a common base for X and Y in a branch and base both topic-x and topic-y on that one. Then optimally both branches would not touch somefile.c any more, but say somefile-x.c and somefile-y.c only.

Alternatively a more advanced tool like topgit might help you (or not :-))