Em termos simples, se você estava prestes a subir em um avião sem conexão com a Internet ... antes de partir, você poderia simplesmente fazê-lo git fetch origin <master>. Seria buscar todas as alterações no seu computador, mas mantê-lo separado do seu desenvolvimento / espaço de trabalho local.
No avião, você pode fazer alterações no espaço de trabalho local e mesclá-lo com o que buscou e resolver possíveis conflitos de mesclagem, tudo sem uma conexão com a Internet. E, a menos que alguém tenha feito novas alterações conflitantes no repositório remoto, depois que você chegar ao destino, você fará git push origin <branch>o café.
Neste incrível tutorial Atlassian :
O git fetchcomando baixa confirmações, arquivos e refs de um repositório remoto no seu repositório local.
Buscar é o que você faz quando deseja ver o que todo mundo está trabalhando. É semelhante à atualização do SVN, pois permite ver como o histórico central progrediu, mas não o força a realmente mesclar as alterações no seu repositório. O Git isola o conteúdo buscado do conteúdo local existente , não tem absolutamente
nenhum efeito no seu trabalho de desenvolvimento local . O conteúdo buscado deve ser retirado explicitamente usando o git checkoutcomando Isso torna a busca de uma maneira segura de revisar confirmações antes de integrá-las ao seu repositório local.
Ao fazer o download de conteúdo de um repositório remoto, git pulle git fetchcomandos estão disponíveis para realizar a tarefa. Você pode considerar
git fetcha versão 'segura' dos dois comandos. Ele fará o download do conteúdo remoto, mas não atualizará o estado de trabalho do repositório local, deixando intacto o trabalho atual. git pullé a alternativa mais agressiva, ele fará o download do conteúdo remoto para a ramificação local ativa e executará imediatamente git mergepara criar uma confirmação de mesclagem para o novo conteúdo remoto. Se houver alterações pendentes em andamento, isso causará conflitos e iniciará o fluxo de resolução de conflitos de mesclagem.
Com git pull:
- Você não recebe nenhum isolamento.
- Isso afeta o seu desenvolvimento local.
- Não precisa ser explicitamente verificado. Porque implicitamente faz a
git merge.
- Basicamente, NÃO é seguro. É agressivo.
- Diferente de
git fetchonde isso afeta apenas o seu .git/refs/remotes, o git pull afetará tanto o seu .git/refs/remotes como .git/refs/heads/
Hmmm ... então, se não estou atualizando a cópia de trabalho git fetch, onde estou fazendo alterações? Onde o Git busca armazenar os novos commits?
Ótima pergunta. Coloca em algum lugar isolado da sua cópia de trabalho. Mas de novo onde? Vamos descobrir.
No diretório do seu projeto (ou seja, onde você executa seus gitcomandos), faça:
ls. Isso mostrará os arquivos e diretórios. Nada legal, eu sei.
Agora faça ls -a. Isto irá mostrar os arquivos de ponto , ou seja, os arquivos começando com .então você vai ser capaz de ver um diretório chamado: .git.
- Faça
cd .git. Obviamente, isso mudará seu diretório.
- Agora vem a parte divertida; faça
ls. Você verá uma lista de diretórios. Estamos procurando refs. Faça cd refs.
- É interessante ver o que está dentro de todos os diretórios, mas vamos nos concentrar em dois deles.
headse remotes. Use cdpara verificar dentro deles também.
- Tudo o
git fetch que você fizer atualizará itens no /.git/refs/remotesdiretório Não atualizará nada no /.git/refs/headsdiretório.
- Qualquer
git pull um primeiro fará os git fetchitens de atualização no /.git/refs/remotesdiretório, depois se fundirá com o seu local e depois mudará a cabeça dentro do /.git/refs/headsdiretório.
Uma resposta relacionada muito boa também pode ser encontrada em Onde o 'git fetch' se coloca? .
Além disso, procure "Notação de barra" na publicação das convenções de nomenclatura do ramo Git . Ajuda a entender melhor como o Git coloca as coisas em diretórios diferentes.
Para ver a diferença real
Apenas faça:
git fetch origin master
git checkout master
Se o mestre remoto foi atualizado, você receberá uma mensagem como esta:
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
Se você não fez fetche acabou de fazer git checkout master, seu git local não saberia que existem dois commits adicionados. E diria apenas:
Already on 'master'
Your branch is up to date with 'origin/master'.
Mas isso está desatualizado e incorreto. É porque o git fornecerá feedback apenas com base no que ele sabe. É inconsciente de novos commits que ainda não foram eliminados ...
Existe alguma maneira de ver as novas alterações feitas no controle remoto enquanto trabalha na filial localmente?
Alguns IDEs (por exemplo, Xcode) são super inteligentes e usam o resultado de a git fetche podem anotar as linhas de código que foram alteradas no ramo remoto do seu ramo de trabalho atual. Se essa linha tiver sido alterada por alterações locais e ramificação remota, essa linha será anotada em vermelho. Este não é um conflito de mesclagem. É um potencial conflito de mesclagem. É um heads-up que você pode usar para resolver o futuro conflito de mesclagem antes de fazer a git pullpartir da ramificação remota.
Dica divertida:
Se você buscou uma ramificação remota, por exemplo:
git fetch origin feature/123
Então isso entraria no diretório de controles remotos. Ainda não está disponível no seu diretório local. No entanto, simplifica seu checkout para essa filial remota com DWIM (faça o que eu quero dizer):
git checkout feature/123
você não precisa mais fazer:
git checkout -b feature/123 origin/feature/123
Para mais informações, leia aqui
