The following is taken directly from the wikipedia article about Git and pretty much sums up my week.
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
Like many of my friends and coworkers, I have a love and hate relationship with Git--mainly hate. However, Git is probably the best and most used source control system out there so we have to use it :)
According to the Git docs the action of the
git cherry-check command is to "Apply the changes introduced by some existing commits". Notice the use of the phrase apply changes rather than merge changes. Cherry picking will not preserve history exactly how it is represented from the source. This will record a new commit SHA.
git cherry-pick command should be a last resort and should be avoided if you can use merge. Cherry picking should only be done either if the source has a completely different history and you want the changes from a single commit and don't care about preserving the history.
If you are still keen to go ahead with the
cherry-pick the syntax is straight forward.
git cherry-pick <commit>
That's it--as long as you don't have any conflicts or if it's a merge commit.
If the commit you want to
cherry-pick is a merge commit then add the flag --parent-number
What is this number I hear you ask? The short answer is--always make it 1. The long answer is in this SO post.
But just use the number
1. It has never failed me :)
git cherry-pick -m 1 <commit>
If you are feeling more adventurous you can Cherry Pick a range of commits.
git cherry-pick <oldest-commit>..<newest-commit>
This will cherry pick each commit from the one after the
oldest-commit to the
cherry-pick will not include the
oldest-commit but will include the
I've just touched the surface of what
git cherry-pick can do, setting up how merge conflicts are handled deserve their own post!