Merging: join two (or more) branches of history. The result is a new commit, which has all the merged commits as parents. A1 |\ A2 B1 A3 B2 | B3 A4 | |

Merging: join two (or more) branches of history. The result is a new commit, which has all the merged commits as parents. A1 |\ A2 B1 A3 B2 | B3 A4 | | / A5 (parents: A4,B3) Cherry-picking: Pick one specific commit from another branch and apply it to the current branch. On your branch the commit gets a new hash (a new identity) since the commit identity is based of a) the parents of a commit and b) the file contents at this commit. There is no information left where the commit came from (aside from author and date). A1 |\ A2 B1 A3 B2 | B3 A4 | A5 resulting from cherry-picking B2 So both methods serve a different purpose: merging brings all of the changes of a branch into another branch; cherry-picking just brings in the changes from one commit into a branch. If you want to bring just one particular change into your branch there's no way around cherry-picking. Another approach is to develop particular things in a topic branch from the start. If you like all of the changes in this branch you can merge it later. The aversion against cherry-picking and its bigger brother rebasing (which basically cherry-picks all the commits of another branch) is based on the basic principle, that each commit represents a somewhat tested state of a program in time. All VCS want to ensure you can go back to these tested states later. Later, if a bug occurs you want to be able to find the commit where the bug was introduced, you can use git's bisect functionality to find this specific commit. There can be two types of bugs: original bugs and integration bugs. In the chery-picking/rebase case you have only one commit for a feature so you cannot easily decide if it is was an original bug or instead introduced by integrating a specific feature. Using merging, you end up having one commit for the feature and one for the merging (integration) and this can help in particular work-flows. You might want to see discussions with and by Linus Torvalds on the linux kernel mailing list about this topic...