0

Let's say we have a branch called Master and another branch called Dev which is based on Master.

We have created several branches out of Dev for different features and it all got merged into Dev.

Then we merged Dev into Master , so now they are similar.

Later on , we had a branch featureA out of dev and then we merged it into dev. Then also we had another branch featureC out of dev and it got merged into dev also.

So now Dev contains featureA & featureC while Master is not

What we want to do is include only the changes made on featureC into Master.

So I thought of using cherry-pick on Master. However when I do so , it shows that there's a conflict and when I review it , it actually showing me all the changes made in featureA & featureC on the source(dev) and I can only add them all to target (master)

You can see below pic for demonstration. I made a small example for better understanding , I can only check both of the commits

So now I have to add all the changes (from A & C) , then remove changes that were made in feature A , this is very risky to do , I believe

am I doing something wrong? because I don't see any benefits of using cherry-pick? The main usage of it is to pick a specific commit from one branch into another and that's not the case above.

Alvaro
  • 51
  • 5
  • 1
    Side note not related to anything: I recommend using all-lowercase for branch names (`master`, `dev`) rather than mixed case like `Master` and `Dev`. The reason is simple enough: some people will mistakenly use all lowercase out of laziness, and for some of them it will *sometimes work and sometimes fail* and they will become confused. – torek Dec 24 '21 at 02:04
  • I'm not sure why your cherry-pick didn't work, but a simple merge of `featureC` into `Master` sould have worked... – Timothy Truckle Dec 24 '21 at 10:38

1 Answers1

0

You can perform a cherry-pick in this case over the range of commits from featureC to master. That will work, and is an easy way to handle this problem. That invocation would often look like git cherry-pick -m1 featureC-merge-commit, assuming that you're using merge commits.

However, because you also have additional changes on dev, those from featureA, you may get conflicts that you have to resolve. That being said, you don't need to either completely accept one side or the other. It is expected that you may need to edit the conflicted code such that it contains only the changes you want to include. If the tool that you're using doesn't allow you to do that, or you don't know how to make it do that, then you may well want to use a different tool, such as a regular text editor, to perform those changes.

bk2204
  • 64,793
  • 6
  • 84
  • 100