You mean the difference between a pull and a cherry-pick? I've been a user of git for a year now and this is my understanding: git pull is just a synonym for t

You mean the difference between a pull and a cherry-pick? I've been a user of git for a year now and this is my understanding: git pull is just a synonym for two commands: git fetch and git merge. git fetch gets a copy of the remote branch you specify, git merge merges that branch into your local one. For the sake of this conversation we're mostly interested in git merge. The primary function of git merge (in this context) is to create a new commit with your local head and the head of the remote branch you just fetched as its parents. git cherry-pick is different. Instead of creating a commit with two other commits as a parent, it creates a commit with just your local head as its parent. So a cherry-pick doesn't bring two branches together. It just extends your local branch by one more node. "Well," I suppose the OP is arguing, "If the point is to take a remote's code and merge it with mine, why would I ever want to pop those changes on top of my own branch, extending it, instead of making a nice tidy commit that merges both branches?" The answer is sometimes (especially when you're working on public projects with anonymous contributers), you don't want all of the changes in a remote branch. You only want some of them. Just the good ones. In those cases, you can't create a commit with the remote head as one of the parents because that would tell git that all of that branch's changes should be merged in, and that's not what you want. What you really want is a ways to rebase just one or two commits from the remote branch onto your local branch. And that is exactly what cherry-pick does. It lets you specify a single commit, then rebases that commit on top of your local branch, extending it. I think the author's problem is he was using this tool thinking it would create commits with both remote and local parents -- that it would merge his branch and the remote one. Instead it created commits that had only his branch as a parent -- that is, it extended his branch. When a tool does something unexpected, it can be scary. But in this case there's no cause for concern. If what he really wanted was to merge the remote and local branches, he cans still do that. Git is smart enough to know which remote commits have already been applied to the local branch via cherry-pick (or any other means). It then just skips those when resolving merges.