Fazer push — o que é, como funciona git push e quando é necessário

O que é um push no Git

Git push é um comando que transfere commits de um repositório local para um remoto. Ao contrário de um commit, que salva alterações apenas na máquina local do desenvolvedor, um push publica essas alterações para toda a equipe. Push é uma etapa obrigatória antes de criar um Pull Request e fazer deploy.

A arquitetura do Git assume que cada desenvolvedor trabalha em seu próprio repositório local. Os commits são criados localmente e se acumulam até que o desenvolvedor decida fazer push. Isso proporciona liberdade: você pode fazer muitos commits locais, experimentar e reescrever o histórico sem afetar os colegas.

# Fazer push para o remote origin, branch main
git push origin main

# Enviar a branch atual para o remote com upstream
git push -u origin feature/new-dashboard

# Enviar todas as branches com nomes correspondentes
git push --all origin

# Force push com lease (push forçado seguro)
git push --force-with-lease

Após um push, o repositório remoto atualiza as refs (referências de branches) para apontar para os novos commits. Outros desenvolvedores podem obter essas alterações via git pull ou git fetch. Essa troca de commits forma a base do desenvolvimento colaborativo.

Como git push funciona

O comando git push compara branches locais e remotas e transfere apenas os commits faltantes. Git não reenvia todos os arquivos — ele transfere apenas o delta, tornando o push rápido mesmo para repositórios grandes. Protocolo Git usa transferência inteligente, que minimiza a quantidade de dados transmitidos.

Se a branch remota contiver commits que não estão presentes localmente, o push será rejeitado. Este é um mecanismo de proteção que evita perda de alterações. Nessa situação, o desenvolvedor deve primeiro executar git pull, mesclar as alterações e só então fazer push novamente. Uma alternativa é o force push, que sobrescreve a branch remota, mas deve ser usado com cautela.

Entender repositórios remotos é fundamental para um push adequado. Normalmente, origin é o nome do repositório remoto padrão. O comando git remote -v mostra a lista de repositórios remotos e suas URLs. Você pode adicionar vários remotes (por exemplo, origin para o repositório principal e upstream para um fork).

Quando fazer push de alterações

A regra principal: faça push após cada etapa de trabalho logicamente concluída. Se um desenvolvedor terminou uma tarefa ou parte dela — é hora de fazer push. No entanto, fazer push de trabalho inacabado que quebra a compilação não é recomendado. Compilação não quebrada é o requisito mínimo para fazer push em qualquer branch.

No desenvolvimento em equipe, adota-se o seguinte ritmo: de manhã — git pull para obter alterações dos colegas, durante o dia — vários commits e um ou dois pushes, à noite — um push final de todas as tarefas concluídas. Quanto mais frequente um desenvolvedor faz push, menor o risco de conflitos de mesclagem e mais transparente o progresso do trabalho.

• Após concluir uma tarefa — commitar e fazer push da solução final para a branch feature
• Antes de sair — fazer push do trabalho inacabado para uma branch feature (não para main!)
• Antes de criar um PR — garantir que todos os commits foram enviados e estão disponíveis para revisão
• Após rebase — fazer push com --force-with-lease para sua branch feature

Regras de push seguro

Push seguro é um conjunto de regras que evitam perda de dados e conflitos na equipe. A primeira e mais importante regra: nunca fazer push diretamente para a branch main ou master se o projeto não tiver deploy direto configurado. Em equipes modernas, a proteção da branch main é configurada no nível de proteção de branch do GitHub.

A segunda regra: sincronize com a branch remota antes de fazer push. Execute git pull --rebase para evitar commits de mesclagem ao unir. Isso simplifica o histórico e o torna linear. Se um push for rejeitado — não use force push simples, primeiro descubra quais commits apareceram na branch remota.

A terceira regra: configure hooks pre-push que executem automaticamente testes e linters antes do envio. Se os testes falharem — o push é bloqueado. Esses hooks são configurados via Husky ou Git hooks (arquivo pre-push em .git/hooks).

A quarta regra: não fazer push de arquivos binários grandes. Git não foi projetado para armazenar artefatos binários — eles incham o repositório e diminuem as operações. Para arquivos grandes, use Git LFS (Large File Storage). Se um binário já foi enviado e está no histórico, ele deve ser removido via git filter-branch.

O que fazer se o push falhar

A causa mais comum de falha no push é que a branch remota contém commits que não estão presentes localmente. Isso acontece quando outro desenvolvedor enviou suas alterações para a mesma branch. Solução: execute git pull, resolva quaisquer conflitos e faça push novamente.

# Push rejeitado — faça fetch e rebase primeiro
git fetch origin
git rebase origin/main
# Resolva os conflitos, depois:
git push --force-with-lease

# Ou simplesmente mescle as alterações remotas
git pull origin main
git push

A segunda razão — falta de permissões de escrita na branch. Se a branch main estiver protegida por regras de proteção de branch, pushes diretos são proibidos. Solução: fazer push para uma branch feature e criar um Pull Request. As configurações de proteção são geralmente administradas via configurações do GitHub ou branches protegidas do GitLab.

A terceira razão — problemas de autenticação. Credenciais desatualizadas, mudança para SSH ou token de acesso pessoal alterado. Solução: verifique a URL remota (git remote -v) e atualize as credenciais. Desde 2021, o GitHub descontinuou a autenticação por senha para HTTPS — use um token pessoal ou chave SSH.