As my concern here is, I have old commit in my another local branch [contains abc.cpp, def.cpp].
Now after few months I want use those changes, but in my current branch abc.cpp is upgraded. So is it like if I cherry pick then it will integrate changes of old abc.cpp into new abc.cpp [recent working directory copy]?
The git-cherry-pick(1) man page says:
Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).
In plain English, this means that git cherry-pick
applies commits from one branch to another, but does not preserve the original history or ancestry from the other branch in the way that a proper merge would do.
Think of it as applying a series of selected patches, rather than a full merge of two branches of history. Obviously, if you tend to make very small, atomic commits then cherry-picking looks exactly like applying a well-written patch. However, since you don't have common ancestors the way you do with merge or rebase, you may have a lot more conflicts to resolve if your commits aren't small and isolated.
Whether or not cherry-picking is a good idea is highly dependent on how you structure your commits. If it doesn't work for you, you can always do things more manually with git format-patch
and git apply
instead.
Yes, that's what it does. cherry-pick
is applying a commit (or a range of them) as a patch to your branch (well, almost as a patch).
You might have conflicts (like when you merge branches) since independent modifications have happened on your branches.
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