0

What does git cherry-pick origin/master mean? How does this instruction work?

When updating current local master branch from remote (i.e., fetch data from remote and merge with local files), we could use the following options:

  • git pull origin master
  • git fetch origin master; git merge origin/master
  • git fetch origin master; git rebase origin/master
  • git fetch origin master; git cherry-pick origin/master

But I cannot understand git cherry-pick origin/master and cannot find the explanation.

I am curious about the following things: when I use git fetch origin master; git cherry-pick origin/master to try to update current local master branch from remote, this action compares previous commits and brings the different parts as modified files, so I can use one commit to includes these modified parts. How does it work?

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
Cythilya
  • 99
  • 1
  • 9
  • 1
    Possible duplicate of [What does cherry-picking a commit with git mean?](https://stackoverflow.com/questions/9339429/what-does-cherry-picking-a-commit-with-git-mean) – phd Jun 17 '18 at 18:59

1 Answers1

4

While merge and rebase work with multiple commits by default, cherry-pick operates on only one commit by default. The cherry-pick command above will not include all commits from origin/master unless specified (or if there's only one additional commit between origin/master and local master).

Issuing git cherry-pick origin/master will take the single commit at the tip of origin/master and apply it to the current working branch.

In addition to how the three commands operate with commits, there are other differences which can be found by looking at the git documentation.

This is a good explanation of cherry-pick: What does cherry-picking a commit with git mean?

sp0gg
  • 3,722
  • 1
  • 17
  • 20
  • Technically, `git merge` *also* takes a single commit besides the current `HEAD` commit, from which it computes a third commit; it then uses those three commits (only) to produce its result. But the process makes s a merge commit, with two parents, which makes it act like it took all the intermediate commits into consideration (but it really didn't!). – torek Jun 17 '18 at 18:04