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]).

The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must be named. If git push [<repository>] without any <refspec> argument is set to update some ref at the destination with <src> with remote.<repository>.push configuration variable, :<dst> part can be omitted—​such a push will update a ref that <src> normally updates without any <refspec> on the command line. Otherwise, missing :<dst> means to update the same ref as the <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].

The special refspec : (or +: to allow non-fast-forward updates) directs Git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.

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

This option overrides this restriction if the current value of the remote ref is the expected value. "git push" fails otherwise.

Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with their commit, and blindly pushing with --force will lose their work.

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> will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value <expect> (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used). If <expect> is the empty string, then the named ref must not already exist.

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.

Note that --force applies to all the refs that are pushed, hence using it with push.default set to matching or with multiple push destinations configured with remote.*.push may overwrite refs other than the current branch (including local refs that are strictly behind their remote counterpart). To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch). See the <refspec>... section above for details.

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.

For example, to default to pushing only the current branch to origin use git config remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be configured as the default for 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

Commits A and B would no longer belong to a branch with a symbolic name, and so would be unreachable. As such, these commits would be removed by a git gc command on the origin repository.