ПО для одновременной разработки

[monolithed]

cкажите, зачем после stash apply делать всё, что есть ниже? (до проф. уровня пользования git'ом ещё не дошло)

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

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

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

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

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

[melky]

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

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

[monolithed]

разве не было бы легче просто вести изменения в свою ветку

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

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

иметь track под рукой?

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

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

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

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

[x-yuri]

monolithed, давай еще раз

# надо исправить критический баг
git stash   # откладываешь текущие изменения
git pull origin branch   # получаешь актуальное содержимое ветки
....   # исправляешь баг, commit, push
git stash apply   # возвращаешься к тому, чем до этого занимался
...   # понимаешь, что надо отменить коммит abcdef
git cherry-pick -nm 1 abcdef   # применяешь коммит (из другой ветки?)
git revert -nm 1 abcdef   # отменяешь его действие

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

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

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

[melky]

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

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

Например, кто-то форкнул твой проект, и вносит туда изменения. Часть изменений тебя интересует.

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

[x-yuri]

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

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

[monolithed]

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

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

[x-yuri]

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

Но не до конца

git cherry-pick -nm 1 abcdef   # применяешь коммит (из другой ветки?)
git revert -nm 1 abcdef   # отменяешь его действие

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

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

[monolithed]

Раз ты делаешь cherry-pick, значит ты хочешь отменить коммит в другой ветке.

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

Но зачем отменять коммит из другой ветки в текущей ветке? Почему не переключиться на нужную ветку и там сделать git revert?

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

git revert -nm 1 hash

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

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

[x-yuri]

значит получается так:

# ВНЕЗАПНО! надо исправить критический баг
$ git stash   # откладываешь текущие изменения
$ git pull origin branch   # получаешь актуальное содержимое ветки
....   # исправляешь баг
$ git commit
$ git push
...
$ git stash pop   # возвращаешься к тому, чем до этого занимался
...
$ git cherry-pick -nm 1 a12345   # копируешь один коммит из другой ветки
...
$ git revert -nm 1 b67890   # отменяешь другой коммит из текущей ветки

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

git init

echo '1
2
3' > 1
git add .
git commit -m 1

git checkout -b 2
echo '1
2
33' > 1
git add .
git commit -m 2

git checkout master
echo '11
2
3' > 1
git add .
git commit -m 2

# git checkout 2        # не работает, если раскомментировать
# git merge master      # и комментарий к reverse неправильный (reversing changes made to ...)
# git checkout master   # потому что в этом случае должно быть -m 2
git merge 2

git revert -m 1 HEAD