-2

I've been working on feature_A while another dev works on feature_B. Now, the other dev needs a small functionallity that's implemented in my feature_A, but I've not finished the whole feature itself. How should I share the code to the other dev? Is it against git-flow branching model? Can I simply merge feature_A into feature_B?

abarazal
  • 369
  • 6
  • 19

1 Answers1

2

Simplest to implement correctly is going to be make a branch off the common base that has just the bits feature-b needs and merge from that to both existing feature tips. Since the code's already in feature-a you can just -s ours merge it.

git checkout -b minifeature-from-a $(git merge-base feature-a feature-b)
hackity hack hack
git commit
git checkout feature-a
git merge -s ours minifeature-from-a
git checkout feature-b
git merge minifeature-from-a

If the existing commits implementing the minifeature are isolated, if they don't also make other changes, "hackity hack hack" above is just a cherry-pick of those commits; if those existing commits also make other changes, it might or might not pay to rebase your own work to achieve that isolation, that's up to you.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • And why is this correctly implemented? Why can I just merge feature_A into feature_B? – abarazal Nov 04 '20 at 03:01
  • 1
    Because this only merges that one detail that feature-b wants, not the rest of what's on feature-a, which I understood you to say is incomplete and still under development. Merge that to feature-b too and you'll have to do your feature-a work on both tips. Yuck. Why do that? – jthill Nov 04 '20 at 03:23
  • I got it. And why not just cherry-pick the commit I want from feature_A? – abarazal Nov 04 '20 at 04:26
  • If you can, do. I said that: "If the existing commits implementing the minifeature are isolated, if they don't also make other changes, "hackity hack hack" above is just a cherry-pick of those commits". – jthill Nov 04 '20 at 05:53
  • I mean, just first `git checkout feature_B` and then `git cherry-pick ` – abarazal Nov 04 '20 at 05:58
  • Cherry-picking straight across works when you can do it, if you don't mind leaving the door open for unnecessary conflicts later, really at that point it's a matter of preference. I like having merges recorded. Cherry-picks are unrecorded selective merges. Other people dislike recorded merges and want everything to *look* as linear as possible, no matter what really happened. If it turns out your minifeature implementation has a bug, the cherry-pick solution leaves you with a scavenger hunt for where the bad code has gotten to and scattershot fixes all over the graph to correct them. – jthill Nov 04 '20 at 06:07