Introdução
O Riverlight Garden precisa de um guia correto para os visitantes. Seu commit local preparado muda a entrada e atualiza o telefone de atendimento aos visitantes. Um colega já publicou uma nova rota sem degraus. Os visitantes precisam das três correções.
Você buscará o trabalho do colega, fará o merge das alterações independentes e publicará o resultado. Um novo clone de recebimento fornecerá os arquivos realmente entregues. O repositório compartilhado e as duas cópias são diretórios locais em uma única máquina de treinamento; trata-se de colaboração real com Git sem um serviço hospedado, configuração de servidor ou conta.
Você já deve reconhecer commits, uma branch, git add, git commit e um diff básico. Nomes de remotos, fetch, merge, push e clone são explicados aqui. A duração de 35 minutos é uma estimativa do autor que inclui leitura e erros comuns.
Descubra a Atualização do Colega
Nesta etapa, descubra por que sua atualização local preparada ainda não pode ser entregue e obtenha a revisão do colega sem alterar seus arquivos.
Abra Terminal. Comece no repositório de edição preparado:
cd /home/labex/project/guide-team/editor
cd altera o diretório de trabalho deste terminal. Se digitar um caminho incorretamente, use pwd para exibir seu diretório atual e ls para listar seu conteúdo; depois, repita o comando cd completo acima. Esses erros comuns de navegação não exigem uma nova VM.
Um novo commit de merge precisará de uma identidade de autor. --local armazena essas configurações apenas neste repositório. O texto entre aspas é um único valor, mesmo quando contém espaços; o e-mail de exemplo é fictício. Você pode escolher seu próprio nome e e-mail.
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Seu commit local existente já está completo. Leia suas informações para visitantes:
cat guide.txt
cat contacts.txt
Você deverá ver South entrance e o telefone de atendimento aos visitantes 010-555-0120. Preserve a frase sobre o horário da última entrada no guia. O arquivo separado da rota ainda informa Use the north ramp:
cat access.txt
git status --short fornece uma lista compacta dos arquivos alterados. A ausência de saída aqui significa que a contribuição preparada está registrada em um commit e que a árvore de trabalho está limpa:
git status --short
Um remoto é uma conexão nomeada com outro repositório. origin é o nome desta conexão, não um servidor especial. -v mostra seus endereços de fetch e push:
git remote -v
Os dois endereços apontam para /home/labex/project/guide-team/shared.git. Este é um repositório bare: ele armazena o histórico compartilhado sem uma cópia de trabalho editável. Não edite seus arquivos internos.
Tente entregar sua branch. push envia commits; main identifica a branch a ser atualizada em origin. Este primeiro push deve falhar com um status de saída diferente de zero. Execute-o separadamente e continue após a rejeição:
git push origin main
Procure [rejected], main -> main e (fetch first). A branch compartilhada contém um trabalho que seu histórico atual não contém, por isso o Git se recusa a substituí-la. Esta é uma atualização sem avanço rápido (non-fast-forward): a ponta compartilhada existente não é um ancestral da ponta proposta. Um push forçado descartaria a contribuição do colega da branch e violaria esta tarefa.
fetch baixa commits remotos e atualiza um ponteiro local de acompanhamento remoto, origin/main. Ele não faz o merge desses commits na sua própria main nem reescreve seus arquivos de trabalho:
git fetch origin
Compare os históricos. --oneline mostra uma linha curta por commit; --graph desenha as conexões entre pais; --all inclui tanto as branches locais quanto as de acompanhamento remoto; --decorate adiciona seus rótulos. --no-pager exibe a saída diretamente; se abrir um paginador ao experimentar, pressione q para sair dele.
git --no-pager log --oneline --graph --all --decorate
Encontre Move the gate and update the visitor desk em HEAD -> main e Update the step-free route em origin/main. Ambos descendem de Open the garden guide. HEAD identifica o commit atualmente em uso na cópia de trabalho. As duas contribuições são diferentes; nenhuma substitui a outra.
Leia a rota do colega diretamente do snapshot dele. show aceita uma expressão revision:path, portanto origin/main:access.txt significa esse arquivo na revisão buscada:
git --no-pager show origin/main:access.txt
Ela informa Use the riverside ramp. Sua rota de trabalho ainda informa Use the north ramp. Essa diferença demonstra que o fetch disponibilizou o novo histórico sem alterar sua árvore de trabalho. O primeiro ponto de verificação aceita essa revisão buscada com seu commit local original ainda intacto.
Combine as Contribuições Independentes
Nesta etapa, combine os dois históricos em uma revisão que contenha a entrada sul, o telefone atualizado de atendimento aos visitantes e a rampa à beira do rio.
Permaneça em Terminal, em /home/labex/project/guide-team/editor. Um merge combina históricos. Como essas alterações afetam arquivos diferentes, o Git consegue combinar seus textos automaticamente. --no-edit aceita a mensagem de merge gerada pelo Git e evita abrir um editor:
git merge --no-edit origin/main
Espere um resumo de merge bem-sucedido, geralmente Merge made by the 'ort' strategy.. O Git cria um commit de merge com dois pais: seu commit original e o commit original do colega. Nenhuma contribuição é reescrita.
Leia os arquivos reais combinados:
cat guide.txt
cat access.txt
cat contacts.txt
O guia deve manter South entrance, 09:00-17:00 e a frase sobre a última entrada; a rota deve informar Use the riverside ramp; o telefone deve permanecer 010-555-0120. As alterações independentes foram combinadas sem conflitos, mas você ainda precisa avaliar seu significado.
Revise o histórico resultante:
git --no-pager log --oneline --graph --all --decorate
O merge em HEAD -> main une as duas linhas de contribuição. origin/main ainda identifica o commit do colega buscado anteriormente até você fazer push. Isso é normal: o merge alterou a main local, não a main compartilhada.
Confira o estado de trabalho:
git status --short
Nenhuma saída é esperada. Se outro experimento deixou um merge em andamento, git merge --abort cancela esse merge inacabado e restaura o estado anterior ao merge; execute-o apenas enquanto houver um merge em andamento e depois repita o comando de merge. Ele não cancela um commit já concluído. O ponto de verificação exige um único commit de merge combinado com os dois pais originais e os três arquivos completos.
Publique e Receba o Guia Completo
Nesta etapa, entregue a revisão combinada ao repositório compartilhado e leia-a em uma nova cópia de recebimento. Um merge local, por si só, ainda não entregou nada a outra cópia.
Permaneça em Terminal, em /home/labex/project/guide-team/editor. push origin main envia o histórico da main local ao repositório chamado origin. Desta vez, a contribuição compartilhada é um ancestral do seu merge, portanto o push pode avançar a main compartilhada sem removê-la.
git push origin main
Espere main -> main sem rejeição. Se houver rejeição, faça fetch e inspecione o grafo novamente; não adicione uma opção de força. Este cenário preparado não tem um colaborador atuando em segundo plano, mas uma equipe real pode publicar novos trabalhos a qualquer momento.
Agora mude para o diretório que contém os dois repositórios:
cd /home/labex/project/guide-team
git clone cria um novo repositório e arquivos de trabalho a partir de uma origem. Aqui, shared.git é o caminho da origem local existente e received-guide é o novo diretório de destino. A cópia de recebimento deve partir do repositório compartilhado, para revelar se o merge foi realmente entregue.
git clone shared.git received-guide
Espere Cloning into 'received-guide'... e done.. Se você já fez o clone ao experimentar, mantenha essa cópia: entre em received-guide e use git fetch origin, ensinado anteriormente, seguido de git merge --no-edit origin/main para atualizá-la. Não exclua o repositório de edição original para tentar um clone novamente.
Entre na cópia de recebimento:
cd received-guide
Leia cada arquivo real. cat exibe um arquivo sem alterá-lo:
cat guide.txt
cat access.txt
cat contacts.txt
Compare as informações com os requisitos de negócio combinados da etapa anterior. Os três arquivos devem estar completos, incluindo as linhas inalteradas. Uma mensagem de clone bem-sucedido, por si só, não comprova que as informações estão corretas.
Por fim, leia o histórico recebido. --oneline resume cada commit, --graph desenha seus vínculos com os pais e --decorate identifica os ponteiros de branch. --no-pager exibe a saída diretamente em vez de abrir um visualizador com rolagem.
git --no-pager log --oneline --graph --decorate
O merge no topo tem duas linhas de ancestralidade, incluindo as mensagens das duas contribuições originais e o commit inicial. Os IDs exatos dos seus commits variam. Confira se nenhum conteúdo foi perdido e se a cópia de recebimento está em main, com uma árvore de trabalho rastreada limpa:
git status --short
Nenhuma saída significa que não há alterações preparadas, não preparadas ou não rastreadas. Você entregou uma coleção útil de arquivos por meio de repositórios Git reais, todos nesta única máquina de treinamento.
Resumo
Você lidou com uma rejeição real de push, buscou o commit de um colega sem sobrescrever seus próprios arquivos, fez o merge de duas contribuições independentes e entregou o guia completo por meio de um repositório compartilhado. Um clone real de recebimento continha o guia combinado, a rota sem degraus e o contato para visitantes.
Os commits originais permanecem no histórico. A seguir, pratique um merge em que o Git precisa do seu julgamento porque duas pessoas alteraram a mesma linha.
