Представь что ты находишься в какой-то ветке, и тебе кидают таск с критическим статусом.
Если внесенных изменений не достаточно для полноценного комита, то логично сделать git stash, чтобы потом к ним вернуться.

В тот момент когда ты делал другой таск в твою ветку что-то запушили. И для того чтобы работать с актуальной версией нужно сделать pull и накатить свои изменения (git stash apply). Тоже самое можно сделать с помощью git stash pop.

Но вот не задача, ты случайно закоммитил файл c каким-то багом, и хочешь убрать из его ветки, для этого есть git cherry-pick.

А git revert -nm 1 ... нужно для того чтобы вырвать пуш из мержда.

И вот ты вернулся к своему таску, все сделал, теперь можно сделать git stash drop, чтобы удалить из стека stash

monolithed, разве не было бы легче просто вести изменения в свою ветку.ю и иметь track под рукой?

... сколько бы я ни читал, всё равно не могу понять работу cherry-pick. Не могли бы вы обьяснить простым языком, зачем она нужна?

До недавнего времени у меня была такая структура проекта:

master
workspace

Сейчас:

master
alpha
feature

Если мне нужно пофиксить какой-то баг или ввести новую фичу, то я создаю ветку feature-1 (постфикс инкрементируется), тестирую, если все гуд, то вливаю в alpha.

Когда протестирую в альфе, переношу в мастер и удаляю feature

alpha нужна потому, что параллельно может делаться несколько фич и если их сразу мерджить в мастер, то все может взорваться.

У меня стандартный workflow выглядит примерно так:

...
git checkout alpha
git checkout -b feature-8628
git pull origin alpha
...
git status
git commit -am 'feature-8628: description'
git push origin feature-8628
git log -p
git checkout alpha
...
git diff HEAD feature-8628
git merge origin/feature-8628
git status
git commit -a
git push origin alpha
git log --graph
git checkout master
git pull origin master
git merge alpha
git diff --staged
git commit -a
git branch -d feature-8628
git push origin master
git log --stat

PS: Для меня такая структура оптимальна, однако для многопользовательской работы над ответственным проектом не помешает еще одна промежуточная ветка test

Причем тут трек?

Я лично использую JetBrains YourTrack, в котором и создаю таски

Выдергивает коммит из ветки, путем создания нового коммита (патч)

monolithed, давай еще раз
А про -m 1 можешь подробнее рассказать? Насколько я понимаю, это на случай если в том коммите будет merge? Можно сказать, что там должна быть единица, не смотря в журнал?

Давай еще я попробую. Копирует отдельный коммит (или несколько коммитов) в текущую ветку, при этом связь (типа merge) не образуется. В первую очередь нужно когда есть несколько веток (репозиториев), которые не предполагается мерджить. Например, кто-то форкнул твой проект, и вносит туда изменения. Часть изменений тебя интересует. Или если надо пофиксить баг в предыдущей версии программы. Cherry pick - это что-то типа "выбирать лучшее".

спасибо, очень просто и в то же время подробно. теперь наконец-то стало понятно, что такое cherry-pick.

карма не плюсюется (

кстати, как забирать изменения из форков?

$ git remote add fork url
$ git fetch fork
$ git cherry-pick ...

Верно понимаешь :)

Но не до конца
Раз ты делаешь cherry-pick, значит ты хочешь отменить коммит в другой ветке. Но зачем отменять коммит из другой ветки в текущей ветке? Почему не переключиться на нужную ветку и там сделать git revert?

И еще там был вопрос: можно сказать, что там должна быть единица, не смотря в журнал?

Может мне наоборот нужно накатить чей-то коммит из другой ветки в свою :)

Преположим что есть ветка alpha, в которую мы подмерджили beta. Помимо ветки beta в мердже участвовали и другие ветки.
И в какой-то момент стало понятно что ветку beta нужно вырвать из итерации. Сделать это безопасно можно так:

git revert -nm 1 hash

В большинстве случаев, да (-m 1 первый коммит)

значит получается так:
по поводу -m, получается, что -m 1 - для той ветки, в которую делали merge: