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
I love Git
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 :)
Apply Changes Introduced by Some Existing Commits.
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.
Avoid Cherry Picking Commits if you can.
Using the 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.
The Syntax for Cherry Pick is straight forward
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.
Using Cherry Pick on 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>
Pick More Than One 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 newest-commit. The cherry-pick will not include the oldest-commit but will include the newest-commit--confusing :s
Just Touched the Surface of What is Available
I've just touched the surface of what git cherry-pick can do, setting up how merge conflicts are handled deserve their own post!
Top comments (0)