Execute a mesclagem e faça o commit com o resultado. Esta opção pode ser usada para substituir a opção --no-commit. Útil apenas quando for mesclar.

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 da mesclagem será limpa antes da confirmação. Para mais detalhes consulte git-commit[1]. Além disso, caso o valor de scissors seja dado ao <mode> , o scissors (tesouras) será anexada ao MERGE_MSG antes de ser repassada para o mecanismo de commit caso exista mesclagens conflitantes.

Apenas atualize para o novo histórico se não houver um histórico divergente local. Esta é a predefinição quando nenhum método de reconciliação dos históricos divergentes for fornecido (através das opções --rebase=*).

Ao fazer a mesclagem em vez do rebase, especifica como uma mesclagem é tratada quando o histórico que foi mesclado já for um descendente do histórico atual. Se a mesclagem for solicitada, a opção --ff é o padrão, a menos que a uma etiqueta mesclada esteja anotada (e possivelmente assinada) e que não esteja armazenada em seu lugar natural na hierarquia refs/tags/, caso onde se assume que a opção --no-ff tenha sido usada.

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]. Útil apenas quando for mesclar.

Adicione uma linha Signed-off-by de quem fez o commit no final da mensagem de registro do commit. O significado de uma aprovação depende do projeto onde você está fazendo o commit. Por exemplo, ele pode certificar que quem fez o commit tem o direito de enviar o trabalho sob a licença do projeto ou concorda com alguma representação do contribuinte, como um certificado de origem do desenvolvedor. (Consulte https://developercertificate.org para saber qual é a usada pelo kernel do Linux e pelos projetos Git). Consulte a documentação ou a liderança do projeto para onde está contribuindo para compreender como as assinaturas são usadas nesse projeto.

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

Produz a árvore de trabalho e condição do índice como se uma mesclagem real tivesse acontecido (exceto pelas informações da mesclagem), mas não faz um commit, move o HEAD ou registra o $GIT_DIR/MERGE_HEAD (para fazer com que o próximo comando git commit crie a mesclagem de um commit). 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 de um "octopus").

É predefinido que os ganchos pre-merge e commit-msg sejam executados. Quando a opção --no-verify é usada, isso é ignorado. Consulte também githooks[5]. Útil apenas quando for mesclar.

Use a estratégia fornecida de mesclagem; mais de uma pode ser fornecida mais de uma vez para especificá-las na ordem em que devem ser testadas. Se não houver a opção -s, uma lista integrada de estratégias será usada em seu lugar (ort ao mesclar um único HEAD, caso contrário, octopus).

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

Verifique se o commit do cume do ramo lateral que está sendo mesclado está assinado com uma chave válida, ou seja, uma chave que tenha uma UID válida: no modelo de confiança predefinido, isso significa que a chave da assinatura foi assinada por uma chave confiável. Se o commit do cume do ramo secundário não for assinado com uma chave válida, a mesclagem será abortada.

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

Crie automaticamente uma entrada temporária de armazenamento antes do início da operação, registre-a na ref MERGE_AUTOSTASH e aplique-a ao concluir a operação. Isso significa que você pode executar a operação numa árvore de trabalho suja. No entanto, use-o com cuidado: o aplicativo de armazenamento final após uma mesclagem bem-sucedida pode resultar em conflitos não triviais.

É 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 usada para substituir este tipo de segurança ao mesclar os históricos de dois projetos que começaram suas vidas de forma independente. Como essa é uma ocasião muito rara, não existe nenhuma variável de configuração para ativar isso por padrão e ela também 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.

Este é um atalho para a opção --rebase=false.

Fetch all remotes, except for the ones that has the remote.<name>.skipFetchAll configuration variable set. This overrides the configuration variable fetch.all`.

Acrescenta os nomes das refs e os nomes dos objetos das refs obtidas ao conteúdo existente do .git/FETCH_HEAD. Sem essa opção, os dados antigos em .git/FETCH_HEAD serão substituídos.

Utilize uma transação atômica para atualizar as refs locais. Ou todas as refs são atualizadas ou por erro, nenhuma será.

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 usada 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 reduza o histórico de um repositório superficial para excluir os commits acessíveis a partir de um ramo ou tag remoto informada. Esta opção pode ser utilizada várias vezes.

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

É predefinido que durante a captura num 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 relate ao servidor os commits acessíveis a partir de todas as refs locais para encontrar commits comuns numa tentativa de reduzir o tamanho do pacote dos arquivos que serão recebidos. Se for especificado, o Git relatará apenas os commits acessíveis a partir das dicas fornecidas. Isso é útil para acelerar as obtenções quando o usuário sabe qual ref local provavelmente terá commits em comum com a ref upstream que está sendo buscada.

Não busque nada do servidor e imprima os argumentos --negotiation-tip=* fornecidos anteriormente e que nós temos em comum com o servidor.

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

Imprima na saída padrão num formato fácil para scripts. Consulte a seção OUTPUT em git-fetch[1] para obter mais detalhes.

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.

Altere o refspec configurado para colocar todos os refs no namespace refs/prefetch/. Consulte a tarefa prefetch em git-maintenance[1].

Antes de obter, remova todas as referências de rastreamento remoto que não existam mais no ramo remoto. As tags não estão sujeitas à poda se forem apenas obtidas devido ao acompanhamento automático da tag predefinida ou devido a uma opção --tags. No entanto, se as tags forem obtidas através de uma refspec explícita (na linha de comando ou na configuração remota, por exemplo, se o ramo remoto tiver sido clonado com a opção --mirror), elas também estarão sujeitas à poda. Usar a opção --prune-tags é um atalho para fornecer a tag refspec.

É predefinido que as tags que apontam para objetos que são baixados do repositório remoto são obtidas e armazenadas localmente. Essa opção desativa o acompanhamento automático de tags. O comportamento padrão de um ramo remoto pode ser especificado com a configuração remote.<nome>.tagOpt. Consulte git-config[1].

Ao obter as refs listadas na linha de comando, use o refspec especificado (pode ser usado mais de uma vez) para mapear as refs nas ramificações de rastreamento remoto, em vez dos valores das variáveis de configuração remote.*.fetch do repositório remoto. Fornecer um <refspec> vazio para a opção --refmap faz com que o Git ignore os refspecs configurados e confie inteiramente nos refspecs fornecidos como argumentos da linha de comando. Consulte a seção "Configurações dos Ramos Monitorados Remotamente" para obter detalhes.

Obtém todas as tags do ramo remoto (ou seja, obtém as tags remotas refs/tags/* em tags locais com o mesmo nome), além de tudo o que seria obtido de outra maneira. O uso dessa opção por si só não sujeita as tags à poda, mesmo que a opção --prune seja usada (embora as tags possam ser podadas de qualquer forma se também forem 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 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 num 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 usada 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 uma ramificação é atualizada à força durante o fetch. Isso pode ser desativado através do fetch.showForcedUpdates, mas 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.

O repositório "remote" é a fonte de uma operação fetch ou pull. Este parâmetro pode ser uma URL (consulte a seção GIT URLS abaixo) ou o nome de um controle remoto (consulte a seção RAMOS REMOTOS abaixo).

Especifica quais as refs que devem ser obtidas via fetch e quais as refs locais devem ser atualizadas. Quando não houver um <refspec> na linha de comando, as refs que serão obtidas com fetch serão lidas a partir das variáveis remote.<repositório>.fetch (consulte a seção "CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE" in git-fetch[1]).