Git: merge only the changes made on the branch
branch, git, git-branch, merge, version-control
Solution
There is no real danger in using cherry-pick, especially if you don't plan on ever merging the `release` branch into `master`.
In general, you can prevent problems like these by basing bug fixes on commits that are included in all branches you want to merge the fix into. In the development of git itself, that is achieved by merging all bug fixes into the `maint` branch (i.e. current stable series which only receives fixes) and then merging that into `master` periodically. That way, the fix is everywhere and the merges are sane.
Problem
``` G---H // Release Branch / / A---B---E---F--- // master \ \ C---D--- // bug fix branch ``` Based on our particular needs for our project, it is quite common for the above scenario to occur. We have our master/dev branch with some commits. Then we get a bug report and start fixing that on the bug branch (commits C and D above). More commits happen in the dev branch in the meantime. Next we are told we need to create a release for a customer which cannot include the changes introduced by commits B, E and F above, but it should include the bug fix. So we branch off of dev before change B was ever applied, but what is the best way to get the bug fix into this release branch too? If I perform a merge of the branch it will include the change that was made in B which I don't want. I could perform a cherry-pick of commits C and D but I read that cherry picking is not always a good idea based on this answer basically because my repo would then look like: ``` G---H---C'---D'--- // Release Branch / / A---B---E---F--- // master \ \ C---D--- // bug fix branch ``` So C' and D' appear as completely new commits with different sha-1 IDs as C and D. Is this really a bad thing? What problems can this lead to? Is there a better way of getting the changes from the bug fix branch into the release branch?