Execute a mesclagem e faça o commit com o resultado. Esta opção pode ser usada para substituir a opção --no-commit.

Chame um editor antes de fazer a mesclagem mecânica de um commit bem sucedido para editar ainda mais a mensagem da mesclagem que foi gerada automaticamente, para que o usuário possa explicar e justificar a mesclagem. A opção --no-edit pode ser utilizada para aceitar a mensagem que foi gerada automaticamente (em geral isso é desencorajado).

Esta opção determina como a mensagem de mesclagem será limpa antes da confirmação. Para mais detalhes consulte git-commit[1]. Além disso, caso o <mode> seja dado o valor de scissors, scissors (tesouras) será anexada a MERGE_MSG antes de ser repassada para o mecanismo de commit caso exista mesclagens conflitantes.

Especifica como uma mesclagem é manipulada quando o histórico mesclado já é um descendente do histórico atual. A predefinição é a opção --ff , a menos que durante a mesclagem de uma tag anotada (e possivelmente assinada) que não seja armazenada em seu local natural na hierarquia refs/tags/, no caso onde a opção --ff não será assumida.

Assine a mesclagem resultante do commit com o GPG. O argumento keyid é opcional e a predefinição retorna para a identidade de quem fez o commit; se utilizado, deve estar anexado a opção 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.

Além dos nomes dos ramos, preencha a mensagem do registro log com descrições de uma linha com no máximo <n> commits atuais que estão sendo mesclados. Consulte também git-fmt-merge-msg[1].

Adicionar uma linha assinado pela pessoa que fez o commit no final do registro log do commit assinado. O significado de uma aprovação depende do projeto, porém normalmente certifica que a pessoa que fez o commit tem o direito de enviar este trabalho sob a mesma licença e concorda com um Certificado de Origem do Desenvolvedor (consulte http://developercertificate.org/ para obter mais informações).

Exiba um "diffstat" no final da mesclagem. O diffstat também é controlado pela opção da configuração merge.stat.

Produza a árvore de trabalho e a condição do índice como se uma mesclagem real tivesse acontecido (exceto as informações da mesclagem), porém não efetue um commit, mova o HEAD ou registre o $GIT_DIR/MERGE_HEAD (para causar o próximo comando git commit para criar uma mesclagem). Isso permite que você crie um único commit sobre o ramo atual, cujo efeito é o mesmo que mesclar um outro ramo (ou mais no caso da mesclagem "octopus").

Esta opção ignora os ganchos dos commits anteriores e os ganchos das mensagens do commit. Consulte também githooks[5].

Use a estratégia de mesclagem informada; podem ser utilizado mais de uma vez para defini-los na ordem em que devem ser tentados. Caso não haja a opção -s, em vez disso será usada uma lista de estratégias incorporada (git merge-recursive ao mesclar um único cabeçalho, caso contrário git merge octopus).

Passe a opção específica da estratégia através da estratégia de mesclagem.

Verifique se o topo do commit do lado do ramo mesclado está assinado com uma chave válida, ou seja, uma chave que possua um uid válida: no modelo de confiança predefinido, isso significa que a chave da assinatura foi assinada através de uma chave confiável. Caso o topo do commit do lado do ramo não seja assinada com uma chave válida, a mesclagem será cancelada.

É um sinônimos para --stat e --no-stat; estas opções foram descontinuadas e serão removidas no futuro.

Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run the operation on a dirty worktree. No entanto, utilize com cuidado: conflitos não triviais podem acontecer caso a aplicação final do "stash" ocorra após uma mesclagem bem-sucedida.

É predefinido que o comando git merge se recuse a mesclar os históricos que não compartilham de um ancestral comum. Esta opção pode ser utilizada para substituir esta segurança durante a mesclagem dos históricos dos dois projetos que iniciaram as suas vidas de forma independente. Como esta é uma ocasião muito rara, não existe variável de configuração para ativar isso de forma predefinida e não será adicionada.

Quando for verdadeiro, reorganize a fundação do ramo atual no topo da ramificação upstream após a busca. Caso haja uma ramificação monitorado remotamente correspondente à ramificação upstream e a ramificação upstream foi reconstruído desde a última busca, a reconstrução da fundação utilizará estas informações para evitar reconstruir as alterações que não fora locais.

Ignora o --rebase anterior.

Capture todos os ramos remotos.

Acrescente nomes ao "ref" e os nomes dos objetos refs capturados ao conteúdo existente de .git/FETCH_HEAD. Sem esta opção, os dados antigos em .git/FETCH_HEAD serão substituídos.

Limite a captura para uma quantidade específica de commits na ponta do histórico de cada ramificação remota. Caso esteja capturando um repositório shallow (superficial) criado pelo git clone com a opção --depth=<profundidade> (consulte git-clone[1]), aprofunde ou encurte o histórico para a quantidade especificada de commits. As tags para os commits aprofundados não são capturados.

Semelhante a opção --depth, exceto que especifica a quantidade de commits do limite raso atual em vez da ponta de cada histórico do ramo remoto.

Aprofunde ou encurte o histórico de um repositório raso para incluir todas os commits acessíveis após a <data>.

Aprofunde ou diminua o histórico de um repositório raso para excluir os commits acessíveis vindos de uma determinada tag ou ramificação remota. Esta opção pode ser utilizada várias vezes.

Caso o repositório de origem esteja completo, converta um repositório raso em um completo, removendo todas as limitações impostas pelos repositórios rasos.

É predefinido que durante a captura em um repositório superficial, o git fetch recuse os refs que exijam a atualização do .git/shallow. Esta opção atualiza o .git/shallow e aceita tais refs.

É predefinido que o Git relatará ao servidor os commits acessíveis de todos as refs locais para que localize os commits comuns na tentativa de reduzir o tamanho do pacote que será recebido. Caso seja utilizado, o Git relatará apenas os commits acessíveis a partir das dicas informadas. Útil para acelerar o processo "fetch" quando o usuário sabe qual a ref local que provavelmente, haverá commits em comum com uma ref upstream que está sendo capturada.

Exiba apenas o que seria feito, sem fazer quaisquer alterações.

Quando git fetch é utilizado com <src>:<dst> "refspec" ele pode se recusar a atualizar o ramo local como discutido na parte <refspec> da documentação do git-fetch[1]. Esta opção sobrescreve esta verificação.

Mantenha o pacote que foi baixado.

Antes de capturar, remova as referências do rastreamento remoto que não exista mais remotamente. As tags não estão sujeitas a remoção caso sejam capturadas apenas por causa do acompanhamento automático da tag predefinida ou devido a uma opção --tags. No entanto, caso as tags seja capturadas por causa de um "refspec" explícito (na linha de comandos ou na configuração remota, por exemplo, caso haja uma clonagem remota com a opção --mirror), elas também estarão sujeitas a remoção. Informar a opção --prune-tags é uma abreviação para informar a tag refspec.

É predefinido que as tags que apontem para os objetos baixados do repositório remoto sejam capturados e armazenadas localmente. Esta opção desativa essa tag automática a seguir. O comportamento remoto predefinido pode ser especificado com a configuração remote.<nome>.tagOpt. Consulte git-config[1].

Ao capturar as refs listadas na linha de comando, utilize o "refspec" informado (pode ser utilizado mais de uma vez) para mapear os refs para as ramificações rastreadas remotamente em vez dos valores das variáveis da configuração remote.*.fetch para o repositório remoto. Informe um <refspec> vazio à opção --refmap faz com que o Git ignore os "refspecs" configurados e confie inteiramente nos "refspecs" informados como os argumentos da linha de comando. Para mais detalhes consulte a seção "Configuração dos Ramos Monitorados Remotamente".

Capture todas as tags remotas (ou seja, capture as tags remotas refs/tags/* nas tags locais com o mesmo nome), além de qualquer outra coisa que possa ser capturada. O uso desta opção por si só não sujeita a remoção das tags, mesmo que --prune seja utilizado (embora as tags possam ser removidas de qualquer maneira, caso também sejam o destino de um "refspec" explícito; consulte --prune).

A quantidade de processos paralelos que serão utilizados para todas as formas de captura.

Caso a captura remota seja bem sucedida, uma referência de rastreamento pull e add será adicionada ao "upstream", utilizado pelo argumento less git-pull[1] e outros comandos. Para mais informações, consulte branch.<nome>.merge e branch.<nome>.remote em git-config[1].

Quando o repositório é informado para capturar e que seja manipulado por git fetch-pack, o --exec=<upload-pack> é passado para o comando utilizar um caminho alternativo para o comando executado na outra extremidade.

É predefinido que a condição geral do progresso seja relatada no fluxo de erros quando estiver conectado em um terminal, a menos que -q seja utilizado. Esta opção impõem a condição geral do progresso, mesmo que o fluxo de erro predefinido não seja direcionado para um terminal.

Transmita a sequência especificada para o servidor ao se comunicar utilizando o protocolo versão 2. A sequência informada não deve conter um caractere NUL ou LF. O tratamento das opções do servidor, incluindo os desconhecidos, é específico do servidor. Quando a opção --server-option=<opção> forem utilizadas várias vezes, todos serão enviados para o outro lado na ordem listada na linha de comando.

É predefinido que o Git verifique se a atualização do ramo foi imposta durante uma captura. Pode ser desativado por meio de fetch.showForcedUpdates, porém a opção `--show-forced-updates garante que essa verificação ocorra. Consulte git-config[1].

É predefinido que o Git verifique se a atualização do ramo foi imposta durante uma captura. Utilize a opção --no-show-forced-updates ou defina fetch.showForcedUpdates como to false para ignorar esta verificação por questões de desempenho. Se utilizada durante o git-pull, a opção --ff-only ainda verificará quais as atualizações foram impostas antes de tentar uma atualização rápida. Consulte git-config[1].

Utilize apenas os endereços IPv4, ignorando os endereços IPv6.

Utilize apenas os endereços IPv6, ignorando os endereços IPv4.

The "remote" repository that is the source of a fetch or pull operation. Este parâmetro pode ser uma URL (consulte a seção GIT URLS abaixo) ou o nome de um ramo remoto (consulte a seção REMOTES abaixo).

Determina quais as refs capturar e quais as refs locais atualizar. Quando nenhum <refspec> aparece na linha de comando, em vez disso, os refs que serão capturados são lidos a partir das variáveis remote.<repositório>.fetch (consulte a seção "CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE" in git-fetch[1]).