Programação B

Colaboração com Repositórios Remotos

Até agora, tudo aconteceu localmente, na sua máquina. Mas para colaborar com outras pessoas, é preciso que o repositório exista em algum lugar acessível por todos. Esse lugar é um repositório remoto (remote).

O serviço mais popular para hospedar repositórios remotos é o GitHub. Existem outros, como GitLab e Bitbucket, mas o GitHub é de longe o mais usado. Ao criar um repositório no GitHub, você obtém uma URL como https://github.com/maria/meu-projeto.git.

Clone

Para obter uma cópia local de um repositório que já existe no GitHub, usamos git clone:

$ git clone https://github.com/maria/meu-projeto.git
Cloning into 'meu-projeto'...
remote: Enumerating objects: 18, done.
remote: Total 18 (delta 4), reused 18 (delta 4), pack-reused 0
Receiving objects: 100% (18/18), done.
Resolving deltas: 100% (4/4), done.

Isso cria um diretório meu-projeto/ com todo o histórico de commits. O repositório clonado já vem configurado com um remote chamado origin, apontando para a URL de onde foi clonado.

Push e Pull

Depois de fazer commits localmente, você envia suas alterações para o remoto com git push:

$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
To https://github.com/maria/meu-projeto.git
   e4f5a6b..b3c4d5e  main -> main

O comando git push origin main envia os commits da branch main local para o remote origin.

Para trazer as alterações que outros membros da equipe enviaram, usamos git pull:

$ git pull origin main
remote: Enumerating objects: 5, done.
remote: Total 5 (delta 2), reused 5 (delta 2), pack-reused 0
Unpacking objects: 100% (5/5), done.
From https://github.com/maria/meu-projeto.git
   b3c4d5e..f6a7b8c  main -> origin/main
Updating b3c4d5e..f6a7b8c
Fast-forward
 contato.html | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 contato.html

O git pull é equivalente a buscar as alterações do remoto (git fetch) e mesclá-las na branch local (git merge). Se houver conflitos, o processo de resolução é o mesmo que vimos antes.

O Fluxo de Trabalho Baseado em Branches

Na prática, equipes raramente fazem commits diretamente na main. O fluxo de trabalho mais comum segue estes passos:

1. O desenvolvedor cria uma branch a partir da main para trabalhar numa funcionalidade específica (ex: adicionar-pagina-contato).
2. Ele faz seus commits nessa branch.
3. Quando a funcionalidade está pronta, ele envia a branch para o remoto (git push origin adicionar-pagina-contato).
4. Ele abre um pull request (PR) no GitHub, que é uma proposta de incorporar as alterações dessa branch na main.
5. Outros membros da equipe revisam o código, fazem comentários e sugerem mudanças.
6. Após aprovação, o pull request é mesclado no main.

Esse fluxo tem duas vantagens importantes. Primeiro, a main nunca recebe código que não foi revisado por outra pessoa. Segundo, cada funcionalidade é desenvolvida de forma isolada, reduzindo a chance de conflitos.

.gitignore

Nem todo arquivo do seu projeto deve ser rastreado pelo Git. Arquivos gerados automaticamente (como node_modules/, que contém dependências baixadas), arquivos de configuração local do editor (como .vscode/settings.json) e, principalmente, arquivos com dados sensíveis (como senhas e chaves de API) não devem ir para o repositório.

Para dizer ao Git quais arquivos ignorar, criamos um arquivo chamado .gitignore na raiz do repositório:

node_modules/
dist/
.env
*.log

Cada linha define um padrão. Nesse exemplo:

• node_modules/ ignora o diretório inteiro de dependências.
• dist/ ignora a pasta de arquivos gerados pelo build.
• .env ignora o arquivo de variáveis de ambiente (que costuma conter senhas).
• *.log ignora qualquer arquivo com extensão .log.

O .gitignore em si deve ser commitado, pois todos os membros da equipe precisam ignorar os mesmos arquivos.