Git

NOME

git-cherry - Encontre os commits que ainda serão aplicados na upstream

RESUMO

git cherry [-v] [<upstream> [<head> [<limite>]]]

DESCRIÇÃO

Determine se há commits em <head>..<upstream> que são equivalentes àqueles no intervalo <limite>..<head>.

The equivalence test is based on the diff, after removing whitespace and line numbers. git-cherry therefore detects when commits have been "copied" by means of git-cherry-pick[1], git-am[1] or git-rebase[1].

Gera o SHA1 de cada commit em <limite>..<head>, prefixado com - para os commits que possuam um equivalente no <upstream> e + para os commits que não tiverem.

OPÇÕES

-v

Exiba os assuntos dos commits ao lado dos SHA1.

<upstream>

Upstream branch to search for equivalent commits. Defaults to the upstream branch of HEAD.

<head>

Ramo de trabalho; A predefinição retorna para HEAD.

<limite>

Não denuncie commits até (e incluindo) limite.

EXEMPLOS

Fluxos de trabalho de patch

git-cherry is frequently used in patch-based workflows (see gitworkflows[7]) to determine if a series of patches has been applied by the upstream maintainer. In such a workflow you might create and send a topic branch like this:

$ git checkout -b topic origin/master
# trabalhe e crie alguns commits
$ git format-patch origin/master
$ git send-email ... 00*

Mais tarde, você pode ver se suas alterações foram aplicadas dizendo (ainda em topic):

$ git fetch  # atualize sua noção de origem/master
$ git cherry -v

Exemplo concreto

Em uma situação em que o tópico consistia em três commits e o mantenedor aplicava dois deles, a situação poderia parecer:

$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) upstream tip commit
[... ignora alguns outros commits ...]
* cccc111 cherry-pick of C
* aaaa111 cherry-pick of A
[... ignora muito mais do que aconteceu ...]
| * cccc000 (topic) commit C
| * bbbb000 commit B
| * aaaa000 commit A
|/
o 1234567 branch point

Nesses casos, o git-cherry exibe um resumo conciso do que ainda precisa ser aplicado:

$ git cherry origin/master topic
- cccc000... commit C
+ bbbb000... commit B
- aaaa000... commit A

Aqui, vemos que os commits A e C (marcados com -) podem ser removidos de sua ramificação` topic` quando você rebase em cima de origidm/master, enquanto o commit B (marcado com +) ainda precisa ser mantido para que seja enviado para ser aplicado a origem/ master.

Utilizando um limite

The optional <limit> is useful in cases where your topic is based on other work that is not in upstream. Expanding on the previous example, this might look like:

$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) upstream tip commit
[... ignora alguns outros commits ...]
* cccc111 cherry-pick of C
* aaaa111 cherry-pick of A
[... ignora muito mais do que aconteceu ...]
| * cccc000 (topic) commit C
| * bbbb000 commit B
| * aaaa000 commit A
| * 0000fff (base) unpublished stuff F
[... snip ...]
| * 0000aaa unpublished stuff A
|/
o 1234567 merge-base between upstream and topic

Especificando base como limite, você pode evitar listar commits entre` base` e topic:

$ git cherry origem/master base de tópicos
- cccc000... commit C
+ bbbb000... commit B
- aaaa000... commit A

VEJA TAMBÉM

git-patch-id[1]

GIT

Parte do conjunto git[1]

scroll-to-top