Repositórios remotos são versões do seu projeto hospedadas na internet (ou em outra rede) que funcionam como um ponto central de colaboração. Eles permitem que você e sua equipe compartilhem alterações, mantenham um histórico centralizado e trabalhem de forma assíncrona. Nesta aula, vamos explorar os comandos fundamentais para enviar e receber alterações, o conceito de forks, como criar pull/merge requests e boas práticas para colaborar em equipe.

Dominar repositórios remotos é essencial para qualquer profissional de DevOps, pois grande parte do fluxo de trabalho moderno depende de plataformas como GitHub, GitLab e Bitbucket.

Push e Pull

Os comandos git push e git pull são os pilares da sincronização entre seu repositório local e o remoto. git push envia os commits do seu branch local para o repositório remoto, enquanto git pull baixa as alterações do remoto e as integra ao seu branch local (equivalente a git fetch seguido de git merge).

Por exemplo, para enviar seus commits para o branch principal do remoto chamado origin, use git push origin main. Para receber as alterações mais recentes, execute git pull origin main. É importante sempre fazer um pull antes de um push para evitar conflitos.

# Adicionar um repositório remoto (se ainda não existir)
git remote add origin https://github.com/usuario/repo.git

# Enviar commits para o remoto
git push -u origin main

# Receber alterações do remoto
git pull origin main

Forks

Um fork é uma cópia de um repositório de terceiros para a sua conta pessoal. Ele permite que você faça alterações sem afetar o projeto original. Forks são comuns em projetos open source: você faz um fork, clona localmente, cria um branch com suas modificações e depois envia um pull request para o repositório original.

Para manter seu fork atualizado com o repositório original, você precisa configurar um remote upstream e fazer fetch/merge periodicamente.

# Fazer fork pelo GitHub (via interface web)
# Depois, clonar seu fork localmente
git clone https://github.com/seu-usuario/repo-forkado.git
cd repo-forkado

# Adicionar o repositório original como upstream
git remote add upstream https://github.com/original/repo.git

# Atualizar seu fork com as alterações do original
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

Pull/Merge Requests

Pull requests (GitHub) e merge requests (GitLab) são mecanismos para propor alterações em um repositório. Você cria um branch com suas modificações e envia um request para que o mantenedor do projeto revise e integre suas mudanças. Isso permite discussão, revisão de código e testes automatizados antes da fusão.

O fluxo típico é: fork, clone, branch, commit, push, criar pull request. Após aprovado, o mantenedor faz o merge. Boas práticas incluem descrever claramente o que foi alterado, referenciar issues e manter commits atômicos.

# Supondo que você já fez um fork e clonou
git checkout -b minha-feature
# Faça alterações, adicione e commit
git add .
git commit -m "Adiciona nova feature"
git push origin minha-feature
# Agora, vá até o GitHub e crie um Pull Request comparando seu branch com o branch main do repositório original

Colaboração

Colaborar em projetos com Git exige organização e comunicação. Algumas práticas recomendadas: usar branches para cada funcionalidade ou correção, manter o branch principal estável, fazer commits frequentes e descritivos, e utilizar pull requests para revisão de código. Ferramentas como Git Flow ou GitHub Flow ajudam a padronizar o fluxo.

Em equipes, é comum proteger branches (ex.: main) para exigir revisões e testes antes do merge. Além disso, resolver conflitos rapidamente e manter o repositório limpo são habilidades importantes. A comunicação via comentários nos pull requests e issues também é fundamental.

# Exemplo de fluxo colaborativo:
# 1. Atualizar seu branch main local
git checkout main
git pull origin main

# 2. Criar um branch para uma nova funcionalidade
git checkout -b feature/login

# 3. Trabalhar, commitar e enviar
git push -u origin feature/login

# 4. Criar Pull Request no GitHub
# 5. Após aprovação, fazer merge (normalmente via interface web)
# 6. Deletar o branch remoto e local
git branch -d feature/login
git push origin --delete feature/login

Boas Práticas

Sempre faça git pull antes de começar a trabalhar para evitar conflitos. Use mensagens de commit claras e no imperativo. Evite fazer commit diretamente no branch principal; crie branches descritivos. Revise seus próprios pull requests antes de pedir revisão. Mantenha seu fork sincronizado com o upstream regularmente.

Referências

Exercícios

  1. Explique a diferença entre git pull e git fetch.

    ✓ Resposta: git fetch baixa as alterações do repositório remoto para o seu repositório local, mas não as mescla automaticamente no seu branch atual. Já git pull faz o fetch seguido de um merge (ou rebase, dependendo da configuração), integrando as alterações diretamente no branch atual.

  2. Qual comando você usaria para enviar seus commits do branch feature-x para o repositório remoto origin?

    ✓ Resposta: git push origin feature-x

  3. Explique o propósito de um fork em projetos open source.

    ✓ Resposta: Um fork cria uma cópia do repositório original na sua conta, permitindo que você faça alterações sem afetar o projeto original. Depois, você pode enviar um pull request para sugerir que suas mudanças sejam incorporadas ao repositório original.

  4. Como você atualiza seu fork com as alterações do repositório original? Descreva os passos.

    ✓ Resposta: Primeiro, adicione o repositório original como um remote chamado upstream (se ainda não tiver). Depois, execute git fetch upstream para baixar as alterações, faça checkout do branch principal (git checkout main) e mescle com git merge upstream/main. Finalmente, envie as atualizações para o seu fork com git push origin main.

  5. Qual a diferença entre um pull request (GitHub) e um merge request (GitLab)?

    ✓ Resposta: Conceitualmente, são a mesma coisa: ambos são solicitações para mesclar alterações de um branch em outro. A diferença é apenas de nomenclatura: GitHub usa "pull request" e GitLab usa "merge request". O fluxo de trabalho é essencialmente o mesmo.