0

We use branches for features which we then merge into master. We also use branches for versions. However, I have a particular feature (merged into master) that needs to go into the version branch. Previously, I had been using cherry-pick for this (manually plucking commits one at a time), but this feature has too many commits to do one at a time. Is there a better way?

This feature has already been merged into master. The branch does not exist locally anymore. However, I do have the commit which resulted from merging it into master.

I am able to restore feature-branch (since we use GitHub). However, from the version branch, when I run git merge feature-branch, I get all sorts of conflicts unrelated to the feature. Same thing happens if I do git rebase feature-branch (from the version-branch).

Scott Weldon
  • 9,673
  • 6
  • 48
  • 67
U Avalos
  • 6,538
  • 7
  • 48
  • 81

2 Answers2

2

Your history might look something like this:

*--*--X--Y---------------* [master]
    \     \             /
     \     *--*--*--*--A [formerly feature-branch]
      \
       *--*--* [version-branch]

The easy part is getting feature-branch back; just figure out the commit hash A and do:

git checkout -b feature-branch A

However, if version-branch branched off of master before feature-branch did (as shown above), you don't want to do a straight git merge or git rebase, because that will also bring in commits X and Y. Instead, do an --onto rebase:

git rebase --onto version-branch Y feature-branch

To make it easier to find Y, you can do:

git merge-base master feature-branch

Or all in one command:

git rebase --onto version-branch $(git merge-base master feature-branch) feature-branch

After the rebase is complete, you can merge into version-branch as usual.

If you get any merge conflicts during the rebase (or if version-branch branched off master at or after feature-branch did and you are still getting conflicts), then you will have to deal with them, because that means the conflicts are between the commits in feature-branch and the commits in version-branch.

Scott Weldon
  • 9,673
  • 6
  • 48
  • 67
0

You will get the merge conflicts in your version branch because the feature branch was based on the master and the (older) version branch has different history (cherry picked commits, merges etc). In your current feature branch there will be additional commits from other unmerged features if it is based on master. So i expect it will be a lot of hard conflict solving work.

I think you even can't rebase. If you rebase the version branch to the to the base of the feature branch, then the cherry picked merges and old solved conflicts of your version branch will be applied again and result in new conflicts.

So in my opinion your process is wrong. If you like to apply new features to older versions, then the feature branch has to be based on the oldest version branch. Otherwise you may change code in your new feature which was never a part of the old version, because it was merged only to master.

I suggest to create different repositories for the versions (forks) and not to use branches for versioning. It makes it easier to maintain. To apply the feature to a different version, push it, after finishing the implementation, to your target version repository in a feature branch. Then you can make the necessary changes in the code, solve conflicts etc. and merge it to the master of your version repo.

Hope that helps.

blndev
  • 494
  • 3
  • 13