Git: explain the difference between rebase and cherry-pick?

Question

git

Since August, I have been actively using git in work and personal projects. It all started with a total misunderstanding and hatred, gradually came to love and admiration.
I studied the official tutorial, read and tried or have already implemented many good practices and, not obvious after SVN, workflow. I feel calm and confident with git, but somehow I still could not understand the difference between rebase and cherry-pick. It seems that both teams, roughly speaking, take it from there and put it here. The same tasks from your daily diet can be done both with the help of one and with the help of the other. But the thought haunts me that it is not for nothing that they are different and that I am missing something. The textbook does not help, Google does not save.
Help me figure out the differences. Maybe there are some specific examples on which the difference will be clearly noticeable.

Answer 1

Everything was beautifully explained by Nkly777 , only in the PS merge block with rebase are mixed up.
I'll add pictures.
git rebase devel - zip dog - "merges" commits by their creation date
(devel branch "dissolves" into the main branch)
git merge devel - fire escape, all devel branch commits are attached to the end, an intersection is formed
(devel remains a separate branch, to which you can return to)
git chery-pick idea - pick up commits from the idea branch

Answer 2

git chery-pick - you pick up commits from one branch to another, this is useful when changes made by another developer in his branch are needed right now in your branch, and in order not to write this code again, you take his commit into your branch
git rebase master - you are synchronized with the main branch to which all the developers of the project commit, this is useful when someone has changed the code section that you are currently working on in your branch, so that in a week you can merge with the master branch without any problems. Usually done every morning before the start of the working day and at the end when the feature is ready.
git merge - usually used when you have 2 or more master branches (for example, master and prototype) there are a lot of commits in these branches (and rebase is not suitable here) and usually after a couple of weeks, the repository maintainer "merges" developments from the prototype branch into master branch by means of this very git merge
PS To make it easier to imagine the difference between git merge and git rebase. Imagine that merge is like a dog with a zipper on clothes - "sews" commits by the date they were created.
Whereas git rebase is like a fire escape - when applied, your commits are attached to the end of the parent branch
git merge use to merge features and fixes into the master branch (as Github does)
and git rebase is used for your branch in which you are working on a feature to pick up the latest changes from the master branch (for this there is a very convenient command `git pull --rebase origin master`, an analogue of 3 commands (`git checkout master; git pull origin master; git checkout mybrach; git rebase master`)

Answer 3

Eh… I don’t even know what else to say here, completely different actions, after all. Roughly speaking, in the first case, the branch is rearranged (with all commits), in the second, a single commit (or several, collapse into one as an option) is patched to another branch. Hence the different uses and different restrictions. And the mechanism is different. To understand the mechanisms, you need to study all sorts of progit and experiment visually on the tree. And if the mechanisms were understood, this question would not 100% arise :)