Bloco 1 · Controlo de versões

Problema sem Git

projecto.html
projecto_v2.html
projecto_v3.html
projecto_v3_FINAL.html
projecto_v3_FINAL_v2.html
projecto_FINAL_FINAL.html
projecto_NOVO_FINAL.html
projecto_FINAL_REAL.html

Caos:

• Que versão é a actual?
• O que mudou entre versões?
• Como combinar trabalho de 2 pessoas?
• O que apagar?

Solução: Git

Git = sistema de controlo de versões distribuído.

• Histórico completo de todas as mudanças.
• Branches para experimentar sem afectar principal.
• Merge para combinar trabalho.
• Distribuído: cópia local + remoto.
• Standard mundial desde 2005.

Terminologia

• Repository (repo): pasta versionada.
• Commit: snapshot de mudanças com mensagem.
• Branch: linha paralela de desenvolvimento.
• Merge: combinar branches.
• Remote: cópia no servidor (GitHub).
• Clone: cópia local de repo remoto.
• Push: enviar commits locais para remoto.
• Pull: receber commits do remoto.

Bloco 2 · Git fundamentos

Setup inicial

# Identificação (1x apenas)
git config --global user.name "Teu Nome"
git config --global user.email "teu@email.com"

# Verificar
git config --list

Comandos essenciais

# Iniciar repo num projecto novo
git init

# Ver estado dos ficheiros
git status

# Adicionar ficheiros ao próximo commit
git add ficheiro.txt
git add .  # tudo

# Criar commit
git commit -m "Mensagem descritiva"

# Ver histórico
git log
git log --oneline  # compacto

Ciclo típico

1. Working Directory (ficheiros que editas)
        ↓ git add
2. Staging Area (preparado para commit)
        ↓ git commit
3. Local Repository (histórico)
        ↓ git push
4. Remote Repository (GitHub)

.gitignore

Ficheiros que não queres versionar:

# .gitignore

# Dependências
node_modules/
__pycache__/

# Build
dist/
build/
*.pyc

# Editor
.vscode/
.idea/
.DS_Store

# Configs sensíveis
.env
*.key
secrets.json

Sempre commit .gitignore logo no início.

Bloco 3 · Branches

Conceito

main:  A--B--C--D
              \
feature:       E--F--G

main: versão estável.
feature: nova funcionalidade isolada.

Permite experimentar sem afectar o resto.

Comandos branches

# Ver branches
git branch
git branch -a  # incluir remotas

# Criar nova branch
git branch feature/login

# Mudar para branch
git checkout feature/login

# Criar + mudar de uma vez
git checkout -b feature/login

# Apagar branch
git branch -d feature/login

Merge

# Estar na branch destino
git checkout main

# Trazer mudanças da feature
git merge feature/login

# Apagar feature após merge
git branch -d feature/login

Resultado:

main:  A--B--C--D--------M
                  \      /
feature:           E--F--G

Merge vs Rebase

Merge: cria commit de merge (M acima).

• Preserva histórico.

Rebase: reescreve histórico.

• Linear, mais limpo.
• Mais avançado, cuidado.

git rebase main

Para iniciantes, usar merge primeiro.

Bloco 4 · GitHub

O que é

GitHub = plataforma cloud para repositórios Git.

• Hosting de código.
• Colaboração entre múltiplos developers.
• Pull requests para revisão de código.
• Issues para gerir bugs/features.
• Actions para CI/CD.
• Pages para sites estáticos.
• Free para repos públicos e privados (com limites).

Alternativas: GitLab, Bitbucket.

Criar repo no GitHub

1. Login em github.com.
2. New repository.
3. Nome, descrição.
4. Público ou privado.
5. Initialize with README.
6. License (MIT standard).
7. Create.

Conectar local ao GitHub

# Primeira vez - já tens projecto local
git remote add origin https://github.com/utilizador/repo.git

# Push primeira vez
git push -u origin main

# Push subsequentes
git push

# Ou: clonar repo existente
git clone https://github.com/utilizador/repo.git
cd repo

SSH vs HTTPS

HTTPS: pedido de password/token a cada push.

SSH (recomendado):

• Gerar chave SSH.
• Adicionar à conta GitHub.
• Push sem password.

# Gerar chave SSH
ssh-keygen -t ed25519 -C "teu@email.com"

# Mostrar chave pública
cat ~/.ssh/id_ed25519.pub
# Copiar e colar nas Settings → SSH Keys do GitHub

Bloco 5 · Pull Requests

Workflow PR

1. Fork (se não és colaborador) ou clone
2. Branch nova (feature/x)
3. Trabalhar, commits
4. Push para o teu fork/repo
5. Abrir Pull Request no GitHub
6. Code review
7. Discussão, ajustes
8. Approve + Merge

PR = mecanismo de revisão de código.

Anatomia de PR

• Título descritivo.
• Descrição do que faz e porquê.
• Reviewers atribuídos.
• Labels (bug, feature, docs).
• Linked issues (#123).
• Commits listados.
• Files changed com diff.
• Conversation com comentários in-line.

Code review

Como reviewer:

• Ler código com atenção.
• Comentar sugestões in-line.
• Aprovar se OK, Request changes se não.
• Construtivo, não pessoal.

Como autor:

• Pequenos PRs (< 400 linhas idealmente).
• Responder a comentários.
• Não levar pessoal.
• Iterar rapidamente.

Bloco 6 · Workflow profissional

Git Flow (clássico)

Branches:

• main: produção estável.
• develop: desenvolvimento integração.
• feature/x: novas features.
• release/x.y: preparação para release.
• hotfix/x: correcções urgentes em produção.

Mais complexo, ideal para projectos grandes.

GitHub Flow (simples, moderno)

Branches:

• main: sempre deployable.
• feature branches: trabalho actual.

Fluxo:

1. Branch from main.
2. Commit changes.
3. Push to GitHub.
4. Open PR.
5. Discuss + review.
6. Merge to main.
7. Deploy.

Recomendado para a maioria dos projectos.

Convenções de commits

Conventional commits:

<tipo>(<scope>): <descrição>

[body]

[footer]

Tipos:

• feat: nova funcionalidade.
• fix: correcção bug.
• docs: documentação.
• style: formatação.
• refactor: refactoring.
• test: testes.
• chore: manutenção.

Exemplos:

• feat(auth): add OAuth2 login
• fix(cart): correct tax calculation

Bloco 7 · Conflitos

Quando ocorrem

Quando 2 branches modificam a mesma linha do mesmo ficheiro.

git merge feature/x
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

Resolver conflitos

Ficheiro fica assim:

<<<<<<< HEAD
Linha vinda do main
=======
Linha vinda da feature
>>>>>>> feature/x

Editar manualmente:

• Decidir qual versão manter (ou combinar).
• Remover marcadores <<<, ===, >>>.

# Após resolver
git add ficheiro.txt
git commit

Estratégias

Preferir uma versão completamente:

git checkout --ours ficheiro.txt   # versão actual
git checkout --theirs ficheiro.txt  # versão a fundir

Abortar merge:

git merge --abort

Ferramentas visuais: VSCode, GitKraken, SourceTree.

Bloco 8 · Boas práticas

Commits

Pequenos e atómicos (1 propósito).
Mensagens claras e descritivas.
Verbos no imperativo ("Add feature" não "Added").
Inglês (norma internacional).
Frequentes (vários por dia).

Commits gigantes com 50 ficheiros.
"fix" como mensagem.
Commits com código que não compila.

Branches

Naming claro: feature/add-login, fix/checkout-bug.
Vida curta (< 1 semana).
Sincronizar com main regularmente.
Apagar após merge.

Branches eternas.
Nomes vagos: temp, test, branch1.

Pull Requests

Pequenos (< 400 linhas).
Descrição completa.
Tests incluídos.
Review antes de merge.

PRs gigantes (1000+ linhas).
Sem descrição.
Self-merge sem review.

Segurança

NUNCA commit:

• Passwords.
• API keys.
• Secrets.
• Dados pessoais.

Use .env + .gitignore.

Se acidentalmente commitou secret:

• Revogar imediatamente.
• Mudar chave/password.
• Limpar histórico (BFG Repo-Cleaner).