Conceito e mecanismo
Um remoto identifica um repositório e configura como obter ou enviar referências. Fetch obtém objetos e atualiza as referências configuradas, permitindo inspeção antes de integrar. Pull combina obtenção com uma integração conforme opções e configuração. Push pede ao servidor que atualize referências. Uma rejeição non-fast-forward pode proteger commits remotos que não estão na tua história local. Não deve ser tratada como simples erro de rede. A autorização do servidor e regras de proteção continuam a condicionar a publicação.
Aplicação guiada
Num exercício com dois clones locais, faz um commit em cada clone a partir da mesma base. Publica o primeiro e observa a rejeição do segundo. No segundo, obtém a história remota, inspeciona a divergência e integra de acordo com a política da equipa antes de voltar a publicar. Se uma reescrita for autorizada, compreende a expectativa protegida por force-with-lease. Um lease não prova que os teus commits contêm todo o trabalho necessário, e referências locais atualizadas em segundo plano podem alterar pressupostos de proteção.
Um hotfix chega ao remoto enquanto trabalhas. O push rejeitado impede que o ignores por acidente. Compara os commits e preserva ambos os objetivos na integração.
Armadilhas comuns
Confundir fetch com alteração automática dos ficheiros da branch atual; usar force para ultrapassar uma divergência não analisada.
Tópicos relacionados: Reverter alterações e preservar trabalho · Diagnóstico e rastreabilidade de releases
Uma rejeição pode proteger trabalho; inspeciona a divergência antes de publicar.
Referência: Git: fetching remote objects · Git 2.56; workflow concepts compatible with modern Git 2.x