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 a "ref" no lado remoto será atualizado com este impulsionamento "push". Expressões arbitrárias não podem ser utilizadas aqui, uma "ref" real deve ser determinada. Caso o comando git push [<repositório>] sem nenhum argumento <refspec> estiver definido para atualizar alguma "ref" no destino com <src> com a variável de configuração remote.<repositório>.push, a parte do comando :<dst> pode ser omitida, este empulsionamento "push" atualizará uma "ref" onde <src> normalmente atualiza sem qualquer <refspec> na linha de comando. Caso contrário, a falta 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 em um "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 as atualizações sem avanço rápido) instrui o Git para enviar as ramificações "coincidentes": para cada ramificação que exista no lado local, o lado remoto é atualizado caso uma ramificação do o mesmo nome já exista.

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

Esta opção substitui esta restrição caso o valor atual da "ref" remota seja o valor esperado. Caso contrário o "git push" vai falhar.

Imagine que você precise refazer o que já foi publicado. Você precisará ignorar a regra "deve avançar rapidamente" para substituir o histórico publicado originalmente através histórico que foi reformulado. Caso alguém construa no topo do seu histórico original enquanto você está fazendo um "rebase", o topo do ramo no ramo remoto pode avançar com o commit dela e impulsionar cegamente com o --force fará com que ela perca o trabalho dela.

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á o ref informado (sozinho), caso seja atualizado, exigindo que o seu valor atual seja o mesmo que o valor definido <expect > (que pode ser diferente do ramo monitorado remotamente que temos para o refname ou nem precisamos ter esse ramo monitorado de forma remota quando este formulário é utilizado). Caso <expect> esteja vazio, então a ref informada já 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.

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 todos os refs que são impulsionados, portanto, utilizá-lo com push.default definido como matching ou com os vários impulsionamentos nos destinos configurados com remote.*.push, pode substituir as outras refs que não sejam o ramo atual (incluindo as refs locais que estão estritamente por trás de sua contraparte remota). Para impor um impulsionamento "push" em apenas um ramo, utilize um + na frente do "refspec" que será impulsionado (como git push origin +master para impor um impulsionamento "push" no ramo master por exemplo). Consulte a seção <refspec>... acima para obter mais detalhes.

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 utilizar como predefinido apenas no ramo atual para origin, utilize git config remote.origin.push HEAD. Qualquer <refspec> válido (como os exemplos abaixo) pode ser configurado como a predefinição para 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 em um 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 um ramo com um nome simbólico, portanto, seriam inacessíveis. Como tal, estes commits seriam removidos por um comando git gc no repositório de origem.