Nope, those changes will be merged in just fine because they are also present in M3 and F3. Therefore, the merge result will have apple.īut wait, what about the changes in commits M1 and F1? They were bypassed by commit P, weren’t they? Are those changes going to be lost? There is no change to the line in question in the master branch relative to the merge base, but in the feature branch, berry changed to apple. Let’s erase all the other commits, since they don’t participate in the merge. The commits involved in the three-way merge are P (the base), M3 (the head of the master branch) and F3 (the head of the feature branch). The merge chooses commit P as the merge base, since it is the most recent common ancestor. Commit F3 changes the line back to apple (undoing our patch) as well as containing the proper fix.Įventually, it comes time to merge the feature branch to the master branch. Meanwhile, in our feature branch, we figure out the proper fix and commit it as F3. On the master branch, commit M3 does additional work unrelated to our patch.
#SOURCETREE CHERRY PICK PATCH#
We then merged commit P into the master branch, and also into the feature branch, producing commits M2 and F2, respectively.Īs before, work continues on both the master and feature branches, and eventually the root cause of the problem is determined, and the patch is reverted in the feature branch and a proper fix applied. We created a new branch called patch based on the common ancestor commit A, and committed our fix to the patch branch as commit P. Here’s the trick: Create a third branch and merge it into both the master and feature branches.
You don’t want to merge the entire feature branch into the master branch, because that would also pick up commit F1. Now you realize that you need to apply a fix to both branches. From a common ancestor A, commit F1 happens on the feature branch, and commit M1 happens on the master branch.
0 kommentar(er)
