Git push

O envio dos marcadores não é automático quando se faz o push de uma ramificação ou se usa a opção --all. O sinalizador --tags envia todos os marcadores locais para o repositório remoto.

O comando git push é mais usado para publicar modificações locais a um repositório central. Após um repositório local ter sido modificado, um comando push é executado para compartilhar as modificações com membros da equipe remota.

O diagrama acima mostra o que acontece quando a ramificação principal local progride mais que a principal do repositório central e você publica modificações com a execução do comando git push origin main. Observe como a execução do git push é quase a mesma coisa que o git merge main de dentro do repositório remoto.

O git push é um dos muitos componentes usados no processo geral de "sincronização" do Git. Os comandos de sincronização operam em ramificações remotas que são configuradas usando o comando git remote. O git push pode ser considerado um comando de "upload", enquanto git fetch e git pull podem ser considerados comandos de "download". Assim que os conjuntos de alterações tiverem sido movidos por meio de um download ou upload, um git merge pode ser feito no destino para integrar as alterações.

Uma prática Git frequente e moderna é ter um repositório --bare de hospedagem remota agindo como repositório de origem central. Esse repositório de origem é, em geral, hospedado fora do local por um host confiável de terceiros, como o Bitbucket. Como o comando push interfere na estrutura de ramificações remotas, é mais seguro e comum fazer o push para repositórios criados com a marcação --bare. Os repositórios vazios não têm um diretório de trabalho, então o comando push não vai alterar nenhum conteúdo do diretório de trabalho em progresso. Para mais informações sobre a criação de repositórios vazios, leia sobre o git init.

O Git evita que você sobrescreva o histórico do repositório central recusando solicitações push quando elas resultam em uma mesclagem sem avanço rápido. Assim, se o histórico remoto for diferente do seu, você precisa fazer o pull da ramificação remota e a mesclagem com a ramificação local e, em seguida, tentar fazer o push de novo. É um processo semelhante ao do SVN para sincronizar com o repositório central via svn update antes de fazer o commit de um conjunto de alterações.

O sinalizador --force substitui esse comportamento e faz com que a ramificação do repositório remoto corresponda ao repositório local, excluindo qualquer modificação upstream que possa ter ocorrido desde a última vez que você usou o comando pull. O único momento em que você talvez precise forçar um push é quando perceber que os commits que acabou de compartilhar não estavam muito corretos e foram corrigidos com um git commit --amend ou com rebase interativo. No entanto, é preciso ter certeza absoluta de que nenhum de seus colegas de equipe fez o pull desses commits antes de usar a opção --force.

Como a gente já verificou que a ramificação principal local estava atualizada, vai ocorrer um merge de avanço rápido e o git push não vai reclamar de nenhum dos itens sem avanço rápido discutidos acima.

O comando git commit aceita uma opção --amend, que vai atualizar o commit anterior. Muitas vezes, o commit é corrigido para atualizar a mensagem de commit ou adicionar novas modificações. Assim que o commit é corrigido, o comando git push não vai funcionar porque o Git vai enxergar o commit corrigido e o commit remoto como conteúdo divergente. A opção --force deve ser usada para enviar um commit corrigido.

O exemplo acima pressupõe que está sendo executado em um repositório existente com um histórico de commits. O git commit --amend é usado para atualizar o commit anterior e, em seguida, fazer o push forçado usando a opção--force.

O comando acima vai excluir o branch remoto chamado branch_name. Inserir um nome de branch prefixado com dois pontos no comando git push exclui o branch remoto.