1

I acknowledge that there are similar questions that have been asked and answered here. Since none of them give me definite answers, I thought asking this question here again. Hope you don't reject this question. With that said:

Scenario

We have a Bitbucket dev branch that stores content related to a specific release (Let's call the branch dev-release-1). Since the next release work starts before the current release is GR, we created another branch for the next release (let's call this branch dev-release-2). It means some people continue to work on the dev-release-1 while working on the new branch. The new branch should have the changes being made in the current release branch as well. The changes in the dev-release-1 branch are minimal and we want to avoid a full merge of dev-release-1 to dev-release-2.

Questions

  1. Is cherry-pick a good option for this scenario? I tried this in our sandbox. Kind of works. Not sure if it will cause a lot of conflicts when we merge all branches into the master. Since cherry-pick results in an entirely new commit ID, I am not sure about it.
  2. Is apply patch a good option? Tried this as well. Comparatively easier to do it with sourcetree. Since it results in an entirely new commit ID, I am not sure about it.
  3. Is there an option to merge a single commit from one branch to another without changing the commit ID?
Community
  • 1
  • 1
Antony
  • 115
  • 1
  • 11

1 Answers1

2

Is there an option to merge a single commit from one branch to another without changing the commit ID?

Not that I know of: the parent of the commit changes, hence its SHA1.
So cherry-pick is one option: you need to test the final merges to master to see if merge conflicts are increased in this case.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250