Geralmente <src> é o nome do ramo que você deseja impulsionar, pode ser qualquer "expressão SHA-1" arbitrária, como master~4 ou HEAD (consulte gitrevisions[7]).

O <dst> informa qual referência no lado remoto é atualizado com este push. Aqui as expressões arbitrárias não podem ser usadas, uma referência real deve ser mencionada. Se o comando git push [<repositório>] sem nenhum argumento <refspec> for definido para atualizar alguma referência no destino com <src> com a variável de configuração remote.<repositório>.push, a parte :<dst> pode ser omitida - este push atualizará uma referência que o <src> normalmente atualiza sem nenhum <refspec> na linha de comando. Caso contrário, a ausência de :<dst> significa atualizar a mesma referência que o <src>.

Caso o <dst> não comece com refs/ (como refs/heads/master por exemplo), tentaremos inferir onde em refs/* no <repositório> de destino, ele pertença com base no tipo da <src> sendo impulsionado e caso o <dst> seja ambíguo.

O objeto referenciado por <src> é utilizado para atualizar a referência <dst> no lado remoto. Caso isso seja permitido, vai depender de onde em refs/* a referência <dst> vive como descrito com mais detalhes logo abaixo, nestas seções "update" indica que quaisquer modificações, exceto as exclusões, que serão descritos nas próximas seções, são tratadas de forma diferente.

O espaço de nomes refs/heads/* aceitarão apenas os objetos commit e será atualizado apenas caso eles possam avançar de forma rápida.

O espaço de nomes refs/tags/* aceitarão quaisquer tipos de objeto (como commits, árvores e bolhas que possam ser marcados) e quaisquer atualizações para eles serão rejeitadas.

É possível impulsionar qualquer tipo de objeto para qualquer espaço de nomes fora do refs/{tags,heads}/*. No caso das tags e dos commits, estes serão tratados como se fossem os commits dentro do refs/heads/* para os propósitos caso a atualização seja permitida.

Um avanço rápido dos commits e das tags fora do refs/{tags,heads}/* por exemplo, é permitido, mesmo nos casos onde o que está sendo acelerado não é um commit e sim um objeto da tag que aponte para um novo commit onde seja um avanço rápido do commit da última tag (ou commit) que está sendo substituindo. Também é permitida a reposição de uma tag por uma outra totalmente diferente, caso ela apontar para o mesmo commit, bem como ao impulsionar uma tag já descascada, ou seja, impulsionar o commit onde o objeto existente do tag aponte ou um novo objeto da tag onde o commit existente esteja apontando.

Os objetos da árvore e da bolha fora do refs{tags,heads}/* serão tratados da mesma maneira como se estivessem dentro do refs/tags/*, qualquer outra atualização deles será rejeitada.

Todas as regras descritas acima sobre o que não é permitido como uma atualização, podem ser substituídas adicionando um sinal opcional + inicial num "refspec" (ou utilizando a opção da linha de comando --force). A única exceção a isso é que nenhuma quantidade de imposição fará com que o espaço de nomes refs/heads/* aceite um objeto que não seja um commit. Os ganchos e configurações também podem substituir ou alterar estas regras, consulte, por exemplo, receive.denyNonFastForwards no git-config[1] e pre-receive e update no githooks[5].

Fazer um impulsionamento "push" de um <src> vazio permite excluir o <dst> "ref" do repositório remoto. As exclusões sempre são aceitas sem um sinal + inicial no "refspec" (ou com a opção --force), exceto quando for proibido pela configuração ou pelos ganchos. Consulte receive.denyDeletes no git-config[1] e pre-receive e update no githooks[5].

O refspec especial : (ou +: para permitir atualizações que não sejam de avanço rápido) direciona o Git a enviar ramificações "correspondentes": para cada ramificação que existe no lado local, o lado remoto é atualizado quando uma ramificação com o mesmo nome já existir no lado remoto.

A tag <tag> significa o mesmo que refs/tags/<tag>:refs/tags/<tag>.

Esta opção substitui essa restrição se o valor atual da referência remota for o valor esperado. Caso contrário, o comando git push falhará.

Imagine que você tenha que fazer o rebase o que já foi publicado. Você terá que contornar a regra "fazer avanço rápido" para substituir o histórico originalmente publicado pelo histórico refeito. Se outra pessoa construiu em cima do seu histórico original enquanto você está fazendo o rebase, o cume do ramo remoto pode avançar com o commit dela, e o push cego feito com --force fará com que o trabalho dela seja perdido.

Esta opção permite que você diga que vai esperar que o histórico que está sendo atualizando seja o que você reconstruiu com o "rebase" e vai querer substituir. Casi uma "ref" remota ainda aponte para um commit específico, você pode ter certeza que outras pessoas não fizeram nada com a "ref". É como fazer uma "concessão" na ref sem bloqueá-la diretamente, a "ref" remota será atualizada apenas caso a "concessão" ainda seja válida.

Somente a opção --force-with-lease, sem qualquer outra definição, protegerá todos as refs remotas que serão atualizadas, exigindo que o seu valor atual seja o mesmo que o ramo monitorado remotamente que temos para eles.

A opção --force-with-lease=<refname>, sem qualquer outro valor esperado, protegerá a "ref" que foi informado (sozinho), caso seja atualizado, exigindo que o seu valor atual seja o mesmo que o ramo monitorado remotamente que temos para isso.

--force-with-lease=<refname>:<expect> protegerá a ref mencionada (sozinha), se ela for atualizada, exigindo que o seu valor atual seja o mesmo que o valor especificado em <expect> (que pode ser diferente da ramificação rastreada remotamente que temos para referência de nome, ou nem mesmo precisamos ter essa ramificação rastreada remotamente quando esse formulário for usado). Se <expect> estiver vazio, então a referência mencionada ainda não deve existir.

Observe que todas as formas diferentes da opção --force-with-lease=<refname>:<expect> que define o valor atual esperado para a "ref" de forma explicita, ainda são experimentais e sua semântica pode mudar à medida que adquiramos mais experiência com este recurso.

A opção --no-force-with-lease cancelará todos os --force-with-lease anteriores na linha de comando.

Uma observação geral sobre a segurança: utilizar esta opção sem um valor esperado, por exemplo, --force-with-lease ou --force-with-lease=<refname> interage muito mal com qualquer coisa que execute de forma implícita o comando git fetch do ramo remoto que será encaminhado para um processo de segundo plano, como o comando git fetch origin no seu repositório para um trabalho agendado "cronjob" por exemplo.

A proteção oferecida contra a opção --force é garantir que as subsequentes alterações onde a base do seu trabalho não sejam prejudicadas, porém isso será derrotado trivialmente caso algum processo em segundo plano estiver atualizando as refs em segundo plano. Não temos nada além das informações de monitoramento remoto, como uma heurística para as refs que você deve ter visto e está disposto a adotar.

Caso o seu editor ou um outro sistema esteja executando o comando git fetch no segundo plano para você, uma maneira de atenuar isso é simplesmente configurar um outro ramo remoto:

Agora, quando o processo em segundo plano executar o comando git fetch origin, as referências no origin-push não serão atualizadas e portanto, comandos como:

Irá falhar a menos que você execute manualmente o comando git fetch origin-push. É claro que esse método será totalmente derrotado por algo que execute o comando git fetch --all, neste caso, você precisa desativá-lo ou fazer algo mais tedioso como:

Crie uma tag base para as versões do código upstream que você viu e está disposto a sobrescrever por exemplo, depois reescreva o histórico e finalmente, imponha um impulsionamento "push" com as alterações para master caso a versão remota ainda esteja na base, independentemente se os seus ramos remotes/origin/master locais foram atualizados em segundo plano ou não.

Alternativamente, ao usar a opção --force-if-includes como uma opção auxiliar em conjunto com --force-with-lease[=<refname>] (sem dizer qual o ref exato do commit remoto, ou quais os refs remotos que estão sendo protegidos por exemplo) no momento do "push", irá verificar se as atualizações a partir dos refs monitorados remotamente tenham sido atualizados de forma implicita em segundo plano e se estão sendo integrados localmente antes de permitir uma atualização forçada.

Esta opção desativa estas verificações e pode causar a perda do commit no repositório remoto; utilize com cuidado.

Observe que a opção --force se aplica a todas as refs que forem enviadas, portanto, usá-lo com push.default definido como matching ou com vários destinos de envio configurados com remote.*.push pode substituir diferentes refs do ramo atual (incluindo as refs locais que estão estritamente atrás de sua contraparte remota). Para forçar um envio para apenas um ramo, use um + na frente do refspec que será enviado (git push origin +master para forçar um envio para o ramo master por exemplo). Para mais detalhes consulte a seção <refspec>... acima.

Esta opção permite uma checagem que verifica se o topo da referência monitorada remotamente é alcançável a partir de uma das entradas "reflog" do ramo local e feita com base nela para uma reescrita. A verificação assegura que quaisquer atualizações do ramo remoto foram incorporadas localmente, rejeitando a atualização forçada se não for esse o caso.

Nenhuma operação será feita caso a opção seja usada sem definir --force-with-lease ou se definir junto com --force-with-lease=<refname>:<expect>.

Usando a opção --no-force-if-includes desativa este comportamento.

Ao usar on-demand ou only, caso um submódulo tenha uma configuração "push.recurseSubmodules={on-demand,only}" ou "submodule.recurse", haverá uma recursão adicional. Nesse caso, "only" é tratado como "on-demand"(sob demanda).

Para uma atualização que falhou, mais detalhes serão dados:

O comportamento predefinido deste comando quando nenhum <refspec> for informado, pode ser configurado definindo a opção push do ramo remoto ou a variável de configuração push.default.

Por exemplo, para fazer o envio predefinido apenas do ramo atual para origin, use o comando git config remote.origin.push HEAD. Qualquer <refspec> válido (como os dos exemplos abaixo) pode ser configurado como o predefinido para o comando git push origin.

Consulte a seção que descreve <refspec> ... acima para uma discussão sobre a combinação semântica.

Isto serve para emular o comando git fetch executado na mothership utilizando o git push que é executado na direção oposta para integrar o trabalho realizado no satellite e geralmente é necessário quando só é possível fazer a conexão num sentido (ou seja, o satélite pode fazer uma conexão ssh com a nave mãe "mothership" mas a nave mãe não pode iniciar a conexão com o satélite porque este está atrás de um firewall ou não está executando o sshd (servidor ssh)).

Depois de executar o comando git push na máquina do satellite, você entraria na mothership e executaria o comando git merge lá para concluir a emulação do comando git pull executada na mothership para obter as alterações feitas no "satellite".

O comando acima alteraria o repositório de origem para

Os commits A e B não pertenceriam mais a uma ramificação com um nome simbólico e, portanto, seriam inacessíveis. Dessa maneira, estes commits seriam removidos por um comando git gc no repositório de origem.