Git 🌙
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-cherry last updated in 2.0.5

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, após a remoção de espaços vazios e os números de linha. Portanto, o git-cherry detecta quando os commits foram "copiados" por através de 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>

O ramo "upstream" para fazer as procuras de commits equivalentes. A predefinição é 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

O git-cherry é frequentemente usado em fluxos de trabalho com base em correções (consulte gitworkflows[7]) para determinar se uma série de correções foi aplicada pelo mantenedor "upstream". Neste fluxo de trabalho, você pode criar e enviar um tópico de ramificação como este:

$ 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

O <limite> opcional é útil nos casos onde o seu tópico tem como base um outro trabalho que não está no "upstream". Expandindo o exemplo anterior, isso pode ter a seguinte aparência:

$ 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