Faz o commit na escolha seletiva. Para conhecer uma lista completa das diferentes maneiras de soletrar os nomes dos commits, consulte o comando gitrevisions[7] O conjunto dos commits também podem ser encaminhados porém é predefinido que nenhuma passagem seja feita, consulte o comando git-rev-list[1] assim como a sua opção --no-walk. Observe que ao definir um argumento para o intervalo, este irá alimentar todos os <commit>…​ percorrendo apenas uma revisão (mais adiante, consulte um exemplo que utiliza maint master..next).

Com esta opção, o git cherry-pick permitirá que você edite a mensagem de commit antes de confirmar.

Essa opção define como a mensagem de commit sera limpa antes de ser encaminhada para o maquinário de commit. Para mais detalhes consulte git-commit[1]. Em particular, caso o valor <mode> tenha um valor de tesoura scissors, a tesoura será anexada a MERGE_MSG antes de ser repassada no caso de um conflito.

Ao gravar o commit, acrescente uma linha que diz "(cherry picked from commit …​)" na mensagem do commit original, indicando de onde a escolha seletiva da alteração deste commit foi feito. Isto é feito apenas para as escolhas seletivas sem conflitos. Não use esta opção caso esteja fazendo uma escolha seletiva do seu ramo privado porque a informação é inútil para o destinatário. No entanto, caso esteja fazendo uma escolha seletiva entre dois ramos publicamente visíveis (como por exemplo, fazendo a atualização retroativa de uma correção para um ramo de manutenção para uma versão de lançamento anterior de um ramo de desenvolvimento), pode ser útil adicionar esta informação.

Costumava ser que o comando predefinia para fazer com a opção -x descrito acima, e a opção -r era para desativá-lo. Agora a predefinição é não utilizar a opção -x, então esta opção não é operacional.

Geralmente você não pode fazer uma escolha seletiva de uma mesclagem porque você não sabe qual o lado da mesclagem principal deve ser considerada. Esta opção determina o número da origem (a partir de 1) do principal e permite que a escolha seletiva repita a alteração em relação a origem informada.

Normalmente, o comando cria automaticamente uma sequência de commits. Esta opção aplica as alterações necessárias para selecionar cada commit informada na sua árvore de trabalho e o índice, sem fazer qualquer commit. Além disso, quando esta opção é utilizada, o seu índice não precisa coincidir ao commit do HEAD. A escolha seletiva é feita contra a condição inicial do seu índice.

Adicione uma linha de assinatura no final da mensagem do commit. Para mais informações, consulte a opção signoff em git-commit[1].

Commits assinados com o GPG O argumento keyid é opcional e a predefinição retorna para a identidade de quem fez o commit; caso seja utilizado, deve estar anexado a opção e sem espaço. A opção --no-gpg-sign é útil para revogar a variável de configuração commit.gpgSign e a anterior --gpg-sign.

Se o atual HEAD é o mesmo que o pai do commit cherry-pick’ed, então um avanço rápido para este commit será executado.

É predefinido que a escolha seletiva de um commit vazio falhará, indicando que é necessário uma chamada explícita do comando git commit --allow-empty. Esta opção substitui este comportamento, permitindo que os commits vazios sejam preservados automaticamente em uma escolha seletiva. Observe que quando "--ff" estiver em vigor, os commits vazios que atendam ao requisito de "avanço rápido" serão mantidos mesmo sem esta opção. Observe também que o uso desta opção mantém apenas os commits inicialmente estão vazios (ou seja, o commit registrou a mesma árvore que o seu pai). Os commits que são tornados vazios devido a um commit anterior são descartados. Para impor a inclusão destes commits, utilize a opção --keke-redundant-commits.

É predefinido que a escolha seletiva irá falhar quando houver um commit com uma mensagem sem nenhum conteúdo. Esta opção substitui este comportamento, permitindo que os commits com mensagens sem nenhum conteúdo possam ser usados.

Caso um commit que esteja sendo escolhido seletivamente duplique um commit já no histórico atual, ele ficará vazio. É predefinido que estes commits redundantes façam com que a escolha seletiva cherry-pick pare para que o usuário possa examinar o commit. Esta opção substitui esse comportamento e cria um objeto commit vazio. implica no uso da opção --allow-empty.

Use a estratégia de mesclagem fornecida. Deve ser usado apenas uma vez. Veja a seção MERGE STRATEGIES em git-merge[1] para detalhes.

Encaminhe a um opção específica até a estratégia de mesclagem. Para mais detalhes, consulte git-merge[1].

Permita que o mecanismo "rerere" atualize o índice com o resultado da resolução automática de conflitos, caso seja possível.

Continue a operação em andamento utilizando as informações existentes em .git/sequencer. Pode ser utilizado para continuar após a resolução dos conflitos em uma falha na seleção ou reversão da escolha seletiva.

Ignore o commit atual e continue com o restante da sequência.

Esqueça a operação atual em andamento. Pode ser utilizado para limpar a condição do sequenciador após uma falha na seleção ou reversão de uma escolha seletiva.

Cancele a operação e retorne a condição pré-sequência.

Aplique a mudança introduzida pelo commit na ponta do branch master e crie um novo commit com esta mudança.

Aplique as alterações introduzidas por todos os commits que são ancestrais do master, mas não do HEAD para produzir novos commits.

Aplique as alterações introduzidas por todos os commits que sejam ancestrais do "maint" ou "next", porém não do "master" ou dos seus ancestrais. Note que o último não significa que maint e tudo entre master e next; especificamente, maint não será usado caso esteja incluso no master.

Aplique as alterações introduzidas pelo quinto e terceiro últimos commits apontados pelo master e crie 2 novos commits com essas mudanças.

Aplique as alterações na árvore de trabalho e no índice que foram introduzidos pelo segundo último commit apontada pelo "master" e pelo último commit apontada pelo próximo, porém não crie nenhum commit com estas alterações.

Caso o histórico seja linear e HEAD seja um ancestral do próximo, atualize a árvore de trabalho e avance o ponteiro HEAD para que coincida com o próximo. Caso contrário, aplique as alterações introduzidas pelos commits que estão na próxima, mas não o `HEAD`para o ramo atual, criando um novo commit para cada nova alteração.

Aplique as alterações introduzidas por todas as confirmações no ramo principal que tocaram no README para a árvore de trabalho e o índice, para que o resultado possa ser inspecionado e transformado em uma única nova confirmação, se adequado.