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>.

O teste de equivalência tem como base no diff, depois de remover os espaços e os números da linha. O comando git-cherry portanto, detecta quando os commits foram "copiados" por meio do git-cherry-pick[1], git-am[1] ou 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>

Ramo "upstream" para procurar os commits equivalentes. A predefinição retorna para o ramo "upstream" do 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

A escolha seletiva é frequentemente utilizado nos fluxos de trabalho com base nos patches (consulte gitworkflows[7]) para determinar se uma série de patches foi aplicada pelo mantenedor "upstream". Neste fluxo de trabalho, você pode criar e enviar o tópico de um ramo como este:

$ git checkout -b topic origem/master
# trabalhe e crie alguns commits
$ git formato-patch origem/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

O <limite> opcional é útil nos casos onde o seu tópico é tem como base em outro trabalho que não está na "upstream". Expandindo o exemplo anterior, isso pode se parecer com:

$ 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