5

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-Y 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?

Michael Härtl
  • 8,428
  • 5
  • 35
  • 62

2 Answers2

1

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.

Hugo Ideler
  • 10,094
  • 2
  • 20
  • 22
  • 1
    Probably the best way. But it requires that there's a clean commit in `topic-X` that only adds the basic stuff in `somefile.c`. In our case the dependencies were not so easy foreseeable, so that there's no such atomic comit. – Michael Härtl May 29 '11 at 11:04
  • @Michael on SO there are tips on how to [cherry-pick only parts of a commit](http://stackoverflow.com/questions/5717026/how-to-git-cherry-pick-only-changes-to-certain-files). – Hugo Ideler May 31 '11 at 12:09
1

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

Uwe Kleine-König
  • 3,426
  • 1
  • 24
  • 20
  • That's what we try, whenever possible. But sometimes we find that out much to late, when topic-X has already seen some progress. We only could split `topic-X` into 2 branches - which again is pretty cumbersome. – Michael Härtl May 29 '11 at 11:01