Git

НАЗВАНИЕ

git-cherry - Поиск коммитов которые ещё не применены вышестоящим репозиторием

ОБЗОР

git cherry [-v] [<вышестоящая-ветка> [<голова> [<ограничение>]]]

ОПИСАНИЕ

Определить, есть ли в вышестоящей ветке (а именно в диапазоне <редакция>..<вышестоящая-ветка>) коммиты эквивалентные тем, что находятся в «локальном» диапазоне <ограничение>..<голова>.

Тест на эквивалентность основан на сравнении списков различий (diff), после удаления из них пробелов и номеров строк. Так что git-cherry выявляет те коммиты, которые были «скопированы» с помощью команд git-cherry-pick[1], git-am[1] или git-rebase[1].

В результате эта команда выводит SHA1 каждого коммита в диапазоне <ограничение>..<голова>, с префиксом минус (-) для коммитов, которые имеют эквивалент в <вышестоящей-ветке>, и плюс (+) — для тех, что не имеют.

ПАРАМЕТРЫ

-v

Выводить заголовки коммитов (их первую строку) после их SHA1.

<вышестоящая-ветка>

Вышестоящая ветка в которой нужно искать эквивалентны коммитов. По умолчанию используется ветка, являющаяся вышестоящей для текущей.

<голова>

Рабочая ветка; По умолчанию: HEAD.

<ограничение>

Не сообщать о коммитах до (и включая) указанный ограничивающий коммит.

ПРИМЕРЫ

Рабочие процессы на основе патчей

git-cherry часто используется при работе с проектами, в которых рабочий процесс, основан на патчах (см. gitworkflows[7]), чтобы определять, была ли серия патчей уже применена в вышестоящем репозитории. В подобном рабочем процессе вы можете создать и отправить ваши изменения из тематической ветки topic следующим образом:

$ git checkout -b topic origin/master
# выполните работу и сделайте несколько коммитов
$ git format-patch origin/master
$ git send-email ... 00*

Позже вы можете проверить, были ли ваши изменения применены, выполнив (все ещё находясь на своей ветке topic):

$ git fetch  # обновить информацию о origin/master
$ git cherry -v

Конкретный пример

В ситуации, когда ветка topic состоит из трёх коммитов, а в вышестоящем репозитории применили только два из них, это может выглядеть следующим образом:

$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) коммит на верхушке вышестоящей ветки
[... вырезаны некоторые другие коммиты ...]
* cccc111 cherry-pick коммита В
* aaaa111 cherry-pick коммита А
[... вырезано много-чего ещё ...]
| * cccc000 (topic) коммит В
| * bbbb000 коммит Б
| * aaaa000 коммит А
|/
o 1234567 точка ветвления

В таких случаях git-cherry может показывать сжатое резюме того, что ещё не было применено:

$ git cherry origin/master topic
- cccc000... коммит В
+ bbbb000... коммит Б
- aaaa000... коммит А

Здесь мы видим, что коммиты А и В (отмеченные минусом, -) можно удалить из вашей ветки topic, когда вы переместите её (с помощью rebase) на верхушку origin/master, в то время как коммит Б (отмеченный плюсом, +), напротив, всё ещё нужно сохранить, чтобы отправить его для применения в origin/master.

Использование аргумента «ограничение»

Необязательный аргумент <ограничение> полезен в тех случаях, когда ваша ветка topic основана на некоторой другой работе, которая пока не опубликована. Расширяя предыдущий пример, это может выглядеть следующим образом:

$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) коммит на верхушке вышестоящей ветки
[... вырезаны некоторые другие коммиты ...]
* cccc111 cherry-pick коммита В
* aaaa111 cherry-pick коммита А
[... вырезано много-чего ещё ...]
| * cccc000 (topic) коммит В
| * bbbb000 коммит Б
| * aaaa000 коммит А
| * 0000fff (base) неопубликованные изменения Г
[... вырезано ...]
| * 0000aaa неопубликованные изменения A
|/
o 1234567 общая база между вышестоящей веткой и topic

Если в качестве ограничивающего коммита вы укажите base, то вы сможете избежать перечисления в выводе всех коммитов между base и topic:

$ git cherry origin/master topic base
- cccc000... коммит В
+ bbbb000... коммит Б
- aaaa000... коммит А

СМОТРИТЕ ТАКЖЕ

git-patch-id[1]

GIT

Является частью пакета git[1]

scroll-to-top