Faz os commits para "cherry-pick". Para obter uma lista mais completa de formas de escrever os commits, consulte gitrevisions[7]. Conjuntos dos commits que podem ser passadas, mas por predefinição, nenhuma travessia é feita, como se a opção --no-walk fosse especificada, consulte git-rev-list[1]. Observe que a especificação de um intervalo alimentará todos os argumentos <commit>…​ para uma única etapa da revisão (veja um exemplo posterior que usa 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 registrar o commit, acrescente uma linha que diga "(cherry picked from commit …​)" à mensagem original do commit para indicar de qual commit essa alteração foi retirada. Isso é feito apenas para escolhas seletivas (cherry picks) sem conflitos. Não use essa opção se estiver fazendo uma seleção seletiva da sua ramificação privada, pois as informações são inúteis para o destinatário. Se, por outro lado, você estiver escolhendo entre duas ramificações visíveis publicamente (por exemplo, fazer o "backport" de uma correção para uma ramificação de manutenção para uma versão mais antiga de uma ramificação de desenvolvimento), adicionar estas informações pode ser útil.

Antigamente, o comando tinha como padrão fazer o -x descrito acima e o -r era para desativá-lo. Agora, a predefinição é não fazer -x, portanto, essa opção não funciona.

Normalmente, não é possível selecionar uma mesclagem porque você não sabe qual lado da mesclagem deve ser considerado como principal. Esta opção especifica o "parent number" ou número principal (a partir de 1) da linha principal e permite que o cherry-pick reproduza a alteração em relação ao principal definido.

Normalmente, o comando cria automaticamente uma sequência de commits. Esta opção aplica as alterações necessárias para selecionar cada commit nomeado em sua árvore de trabalho e no índice, sem fazer qualquer commit. Além disso, quando esta opção é usada, seu índice não precisa corresponder ao commit do HEAD. A seleção seletiva (cherry-pick) é feita em relação ao estado inicial do seu índice.

Adicione uma linha Signed-off-by no final da mensagem de confirmação. Consulte a opção signoff do comando git-commit[1] para obter mais informações.

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.

By default, cherry-picking an empty commit will fail, indicating that an explicit invocation of git commit --allow-empty is required. This option overrides that behavior, allowing empty commits to be preserved automatically in a cherry-pick. Note that when "--ff" is in effect, empty commits that meet the "fast-forward" requirement will be kept even without this option. Note also, that use of this option only keeps commits that were initially empty (i.e. the commit recorded the same tree as its parent). Commits which are made empty due to a previous commit will cause the cherry-pick to fail. To force the inclusion of those commits, use --empty=keep.

É predefinido que um commit com uma mensagem vazia falhe durante uma seleção seletiva (cherry-pick). Essa opção substitui este comportamento permitindo que os commits com mensagens vazias sejam escolhidas a dedo.

How to handle commits being cherry-picked that are redundant with changes already in the current history.

Deprecated synonym for --empty=keep.

Use a estratégia de mesclagem fornecida. Deve ser utilizada apenas uma vez. Consulte a seção ESTRATÉGIAS DE MESCLAGEM do comando git-merge[1] for details.

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

Depois que o mecanismo rerere reutilizar uma resolução registrada no conflito atual para atualizar os arquivos na árvore de trabalho, permita que ele também atualize o índice com o resultado da resolução. A opção --no-rerere-autoupdate é uma boa maneira de verificar novamente o que o rerere fez e detectar possíveis erros de mesclagem, antes de fazer o commit resultante no índice com um comando git add separado.

Continue a operação em andamento usando as informações em .git/sequencer. Pode ser usado para continuar após uma falha da resolução de conflitos num "cherry-pick" ou numa reversão.

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

Esqueça a operação atual em andamento. Pode ser usado para limpar a condição de falha do sequenciador após um "cherry-pick" ou uma reversão.

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 maint ou do próximo, nem do master ou de qualquer um de seus ancestrais. Observe que o último não significa maint e tudo entre master e next; especificamente, maint não será usado se estiver incluído em 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.

Se o histórico for linear e HEAD for um ancestral do próximo, atualize a árvore de trabalho e avance o ponteiro HEAD para a próxima correspondência. Caso contrário, aplique as alterações introduzidas por estes commits que estão próximos, mas não são o HEAD do 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 numa única nova confirmação, se adequado.