I
I
Ilya Bondarenko2015-09-08 18:20:49
git
Ilya Bondarenko, 2015-09-08 18:20:49

How to merge only branch changes, but not ancestors?

There is roughly the following commit history:

  C7---C8             #release_v2
  /
 /
C1---C2---C5---C6---    #dev
      \        /
       \      /
        C3--C4     #my_super_feature

When trying to merge my_super_feature into release_v2, changes made in commit C2 are also included in the release. Between C1 and C2 there can be commits C1.1, C1.2, C1.n which will also fall into the merge commit.
Of course, you can use Cherry-pick, but there are dozens of commits in a feature branch. Or you can "branch" all features from C1, but you want dev to always have the latest edits on features, and new features start from the last commit in dev .
Is there a way to merge only the C3 and C4 commits from my_super_feature into the release branch, excluding changes made to C2 and everything before it?
If this is not possible, then please advise how else to organize branches so that new features branch off from the latest version of the project (not even stable) and merge both in dev and in release, provided that it is not known which feature will be included in the upcoming release.

Answer the question

In order to leave comments, you need to log in

2 answer(s)
A
aol-nnov, 2015-09-08
@bondarenko

if it’s not clear what will go into the next release, you need to start all the features from one commit.
but I would do it differently:
make a feature branch from #dev, sausage the feature as it is ready - rebase it to the edge of #dev, review the code, (then optionally sqash the whole feature to 1 commit), merge to #dev. Then another, and another. Testing-shmesting, how everything calmed down, from this place in #dev you make a separate #release branch or rebase here the branch with which you make releases or just put a tag.
the release has passed, what feature is completed, you rebase it to the edge of #dev and everything is in a circle.
with this approach, you can clearly see what will get into the release (since it has already been completed and is in #dev)

A
Alexey Shumkin, 2015-09-09
@ashumkin

then please advise how else to organize the branches ...

A good branching model for Git won't work?

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question