Menu
Let's imagine that we have a master branch.
Then we create a newbranch
git checkout -b newbranch and make two new commits to newbranch: commit1 and commit2
Then we switch to master and make cherry-pick
git checkout master git cherry-pick hash_of_commit1 Looking into gitk we see that commit1 and its cherry-picked version have different hashes, so technically they are two different commits.
Finally we merge newbranch into master:
git merge newbranch and see that these two commits with different hashes were merged without problems although they imply that the same changes should be applied twice, so one of them should fail.
Does git really do a smart analysis of commit's content while merging and decide that changes shouldn't be applied twice or these commits are marked internally as linked together?
468
This command is also beneficial for undoing changes related to the past development done by the team. For instance, if we accidentally made a commit to the wrong branch, we will shift to the correct branch and cherry-pick the commit to the right place where it should belong in a new branch of the repository.
Cherry picking is the act of picking a commit from a branch and applying it to another. git cherry-pick can be useful for undoing changes. For example, say a commit is accidently made to the wrong branch. You can switch to the correct branch and cherry-pick the commit to where it should belong.
Yes, at least with the standard git setup. You cannot cherry-pick while there are conflicts. Furthermore, in general conflicts get harder to resolve the more you have, so it's generally better to resolve them one by one. That said, you can cherry-pick multiple commits at once, which would do what you are asking for.
In GitHub Desktop, click Current Branch. In the list of branches, click the branch that has the commit that you want to cherry-pick. Click History. Drag the commit that you want to cherry-pick to the Current Branch menu and drop the commit on the branch that you want to copy the commit to.
Don't worry, Git will handle it.
Unlike e.g. SVN1, Git does not store commits in delta format, but is snapshot-based2,3. While SVN would naively try to apply each merged commit as a patch (and fail, for the exact reason you described), Git is generally able to handle this scenario.
When merging, Git will try to combine the snapshots of both HEAD commits into a new snapshot. If a portion of code or a file is identical in both snapshots (i.e. because a commit was already cherry-picked), Git won't touch it.
Sources
1Skip-Deltas in Subversion
2Git Basics
3The Git object model
56
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
