UC00617

Git e GitHub

Controlo de versões, branching, collaboração

Curso profissional · 25h · Tools essenciais para developers

Plano

  1. Conceitos de controlo de versões
  2. Git fundamentos
  3. Branches e merging
  4. GitHub
  5. Pull requests
  6. Workflow profissional
  7. Resolução de conflitos
  8. Boas práticas

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).

UC00617 · resumo

  • Git = controlo de versões, GitHub = cloud para Git.
  • Commits atómicos com mensagens claras.
  • Branches para isolar trabalho.
  • Pull Requests para colaboração e review.
  • Convenções (conventional commits) ajudam equipa.
  • Conflitos resolvem-se manualmente.
  • Segurança: nunca commit secrets.
  • Standard mundial — essencial para qualquer developer.

NOTAS DO PROFESSOR 📖 O problema que o Git resolve Este slide é deliberadamente caricato, mas quase todos os formandos já viveram esta confusão de ficheiros com FINAL_v2. Convém deixá-los rir e reconhecer-se no exemplo antes de apresentar a solução. A ideia é criar a necessidade: mostrar a dor do controlo de versões manual para que o Git apareça como alívio. 🗣️ Pontos a desenvolver oralmente • Perguntar quem já teve uma pasta assim no computador • Discutir o caos de combinar trabalho de duas pessoas sem ferramenta • Antecipar que cada um destes problemas tem resposta direta no Git

NOTAS DO PROFESSOR 📖 O que é o Git O Git responde diretamente a cada problema do slide anterior: histórico, branches, merge e cópias distribuídas. O conceito de distribuído é o mais importante e o mais difícil: cada developer tem o repositório completo no seu computador, não só uma cópia parcial. Convém sublinhar que ser o standard mundial significa que esta competência é transversal a qualquer linguagem ou empresa. 🗣️ Pontos a desenvolver oralmente • Explicar o que significa ser distribuído e porque é vantajoso • Ligar cada funcionalidade ao problema correspondente do slide anterior • Reforçar que aprender Git serve para toda a carreira, não só este curso

NOTAS DO PROFESSOR 📖 Terminologia fundamental Vale a pena dominar este vocabulário antes de tocar em comandos, porque tudo o resto assenta nele. Os termos mais confundidos são clone, push e pull, e convém fixar a direção de cada um: push envia, pull recebe. Reforçar que o commit é a unidade básica, um instantâneo do projeto acompanhado de uma mensagem que explica a mudança. 🗣️ Pontos a desenvolver oralmente • Fixar a direção de push e pull com um gesto ou diagrama • Distinguir repositório local de remoto desde o início • Explicar porque cada commit precisa de uma boa mensagem

NOTAS DO PROFESSOR 📖 Configuração inicial do Git Esta configuração faz-se uma única vez por máquina e é frequentemente esquecida, o que leva a commits com identidade errada. Convém explicar que o nome e email aqui definidos aparecem em cada commit e ficam no histórico permanente. Vale a pena verificar com config --list que a turma o fez corretamente antes de avançar. 🗣️ Pontos a desenvolver oralmente • Sublinhar que esta configuração se faz só uma vez por computador • Explicar onde este nome e email vão aparecer depois • Recomendar usar o mesmo email da conta GitHub

NOTAS DO PROFESSOR 📖 Comandos essenciais Estes poucos comandos cobrem mais de oitenta por cento do uso diário do Git. O hábito mais importante a incutir é correr git status constantemente, antes e depois de cada ação, para nunca trabalhar às cegas. Convém praticar o ciclo completo, de init a commit, com um ficheiro de teste para fixar a sequência. 🗣️ Pontos a desenvolver oralmente • Incutir o reflexo de correr git status a toda a hora • Distinguir adicionar um ficheiro de adicionar tudo com o ponto • Mostrar a diferença entre git log e git log --oneline

NOTAS DO PROFESSOR 📖 O ciclo de trabalho típico Este diagrama é o mapa mental que evita a maior parte da confusão dos iniciantes. A staging area é o conceito mais difícil: é a antecâmara onde se prepara o que vai entrar no próximo commit. Convém usar a analogia de encher um carrinho de compras antes de pagar, para explicar porque o add e o commit são passos separados. 🗣️ Pontos a desenvolver oralmente • Explicar a staging area com a analogia do carrinho de compras • Percorrer o diagrama nomeando o comando de cada seta • Esclarecer porque add e commit não são o mesmo passo

NOTAS DO PROFESSOR 📖 O ficheiro .gitignore O .gitignore evita versionar lixo como dependências e ficheiros temporários que poluem o repositório. O ponto crítico de segurança é a última secção: nunca versionar ficheiros de configuração sensível como .env ou chaves. Convém criar o .gitignore logo no primeiro commit, antes de adicionar qualquer outra coisa, para não correr riscos. 🗣️ Pontos a desenvolver oralmente • Explicar porque não se versiona a pasta de dependências • Alertar para o perigo de comprometer ficheiros .env com segredos • Recomendar começar de modelos prontos de .gitignore por linguagem

NOTAS DO PROFESSOR 📖 O conceito de branch As branches são a funcionalidade que torna o Git poderoso para trabalho em equipa. O diagrama mostra a ideia essencial: uma linha paralela onde se experimenta sem mexer no código estável. Convém usar a analogia de um documento copiado para rascunho, onde se testa à vontade antes de aplicar ao original. 🗣️ Pontos a desenvolver oralmente • Explicar a branch com a analogia de um rascunho seguro • Sublinhar que a main deve manter-se sempre estável • Mostrar como duas pessoas podem trabalhar em paralelo sem se atrapalhar

NOTAS DO PROFESSOR 📖 Comandos de branches O comando que mais vale a pena automatizar como reflexo é o checkout -b, que cria e muda de branch num só passo. Convém alertar que mudar de branch troca os ficheiros visíveis na pasta, o que costuma surpreender quem está a começar. Praticar criar, mudar e apagar branches com nomes descritivos fixa o fluxo e as boas convenções de nomes. 🗣️ Pontos a desenvolver oralmente • Destacar o atalho checkout -b para criar e mudar de uma vez • Explicar porque os ficheiros mudam ao trocar de branch • Reforçar nomes claros como feature/login em vez de vagos

NOTAS DO PROFESSOR 📖 O merge O merge é o momento em que o trabalho isolado regressa à linha principal. O detalhe que mais confunde é a ordem: é preciso estar na branch de destino antes de fazer o merge, não na de origem. Convém praticar o fluxo completo: mudar para a main, fazer merge da feature e depois apagar a branch já incorporada. 🗣️ Pontos a desenvolver oralmente • Insistir na regra de estar na branch destino antes do merge • Ler o diagrama identificando o commit de merge resultante • Mostrar o hábito de apagar a branch depois de fundida

NOTAS DO PROFESSOR 📖 Merge versus rebase Esta distinção gera debates acalorados entre profissionais, mas para a turma a mensagem é simples e está na última linha: começar pelo merge. O merge preserva o histórico tal como aconteceu, enquanto o rebase o reescreve para ficar linear e mais limpo. Convém avisar que o rebase é poderoso mas perigoso quando mal usado em trabalho partilhado. 🗣️ Pontos a desenvolver oralmente • Resumir a diferença: merge preserva, rebase reescreve • Explicar porque o rebase fica para mais tarde, depois de dominar o merge • Alertar para o risco de reescrever histórico já partilhado

NOTAS DO PROFESSOR 📖 O que é o GitHub É essencial separar bem os conceitos: o Git é a ferramenta, o GitHub é a plataforma na nuvem que aloja repositórios Git. Pode usar-se Git sem GitHub, mas a colaboração moderna passa quase sempre por uma plataforma destas. Convém destacar que o GitHub é hoje também um portefólio público que os recrutadores consultam. 🗣️ Pontos a desenvolver oralmente • Insistir na distinção entre Git e GitHub, que muitos confundem • Apresentar o GitHub como portefólio visível para empregadores • Mencionar que GitLab e Bitbucket fazem o mesmo papel

NOTAS DO PROFESSOR 📖 Criar um repositório no GitHub Este é um processo guiado que a turma deve fazer ao vivo, criando o seu primeiro repositório real. Convém discutir a escolha entre público e privado, e o que isso implica para a visibilidade do código. Inicializar com README e escolher uma licença logo no início são bons hábitos profissionais que vale a pena explicar. 🗣️ Pontos a desenvolver oralmente • Acompanhar cada formando a criar o seu primeiro repositório • Discutir quando faz sentido público ou privado • Explicar o papel do README e da licença num projeto

NOTAS DO PROFESSOR 📖 Conectar o local ao GitHub Há dois caminhos que convém não baralhar: ligar um projeto local já existente a um remoto novo, ou clonar um remoto já existente. O detalhe técnico a sublinhar é a flag -u no primeiro push, que estabelece a ligação entre a branch local e a remota. Praticar ambos os cenários ajuda a turma a saber qual usar em cada situação. 🗣️ Pontos a desenvolver oralmente • Distinguir os cenários de remote add e de clone • Explicar o que faz a flag -u no primeiro push • Mostrar como verificar o remoto configurado

NOTAS DO PROFESSOR 📖 SSH versus HTTPS A vantagem prática do SSH é não ter de introduzir credenciais a cada push, o que poupa fricção diária. Convém explicar o conceito de par de chaves de forma simples: a privada fica no computador, a pública partilha-se com o GitHub. Embora seja um passo de configuração inicial mais técnico, vale o investimento e é boa altura para o praticar com calma. 🗣️ Pontos a desenvolver oralmente • Explicar o par chave pública e privada com uma analogia de cadeado • Sublinhar que a chave privada nunca se partilha • Acompanhar a geração da chave e o registo no GitHub

NOTAS DO PROFESSOR 📖 O workflow do pull request O pull request é o coração da colaboração profissional e do que os recrutadores valorizam ver. Convém fixar que o PR não é só técnico: é o momento de revisão, discussão e melhoria do código antes de entrar na main. Percorrer os oito passos com a turma desmistifica o processo e prepara-os para o trabalho real em equipa. 🗣️ Pontos a desenvolver oralmente • Distinguir o fluxo com fork do fluxo como colaborador direto • Sublinhar o PR como ponto de revisão, não só de junção • Acompanhar a abertura de um PR real no GitHub

NOTAS DO PROFESSOR 📖 Anatomia de um pull request Conhecer as partes de um PR ajuda a criar pedidos claros e fáceis de rever. O elemento mais negligenciado é a descrição: explicar o que o PR faz e porquê poupa imenso tempo a quem revê. Convém destacar a ligação a issues com o cardinal, que conecta o trabalho ao planeamento e fecha tarefas automaticamente. 🗣️ Pontos a desenvolver oralmente • Mostrar um PR real e identificar cada secção • Insistir numa boa descrição que explique o porquê • Demonstrar a ligação a uma issue com o número precedido de cardinal

NOTAS DO PROFESSOR 📖 A revisão de código A revisão de código é tanto técnica como humana, e a dimensão humana costuma ser esquecida. A regra de ouro está nos dois lados: o reviewer comenta de forma construtiva e não pessoal, e o autor não leva os comentários a peito. Convém preparar a turma para esta cultura, que pode ser desconcertante para quem nunca teve o seu código examinado por outros. 🗣️ Pontos a desenvolver oralmente • Modelar um comentário de revisão construtivo versus um pessoal • Explicar porque PRs pequenos são mais fáceis e rápidos de rever • Normalizar receber pedidos de alteração como parte do processo

NOTAS DO PROFESSOR 📖 O modelo Git Flow O Git Flow é o modelo clássico, com várias branches de longa duração para diferentes propósitos. Convém apresentá-lo como referência histórica e como solução para projetos grandes com releases planeados. Importa não assustar a turma: é mais complexo do que precisam agora, e serve sobretudo para perceberem por contraste o modelo simples que vem a seguir. 🗣️ Pontos a desenvolver oralmente • Explicar o papel de cada branch, de develop a hotfix • Enquadrar o Git Flow como adequado a projetos grandes e com versões • Preparar o contraste com o GitHub Flow do próximo slide

NOTAS DO PROFESSOR 📖 O modelo GitHub Flow Este é o modelo a recomendar à turma: simples, moderno e suficiente para a maioria dos projetos. A regra central é que a main está sempre pronta a publicar, e todo o trabalho passa por branches curtas e pull requests. Convém contrastá-lo com o Git Flow para mostrar que menos complexidade costuma ser melhor quando a equipa não é enorme. 🗣️ Pontos a desenvolver oralmente • Percorrer os sete passos do fluxo com um exemplo • Sublinhar o princípio de manter a main sempre publicável • Justificar porque este modelo serve a maioria dos casos reais

NOTAS DO PROFESSOR 📖 Convenções de commits As convenções de commits dão consistência ao histórico e até permitem gerar changelogs automaticamente. O formato tipo-âmbito-descrição parece rígido, mas torna o histórico legível e pesquisável por toda a equipa. Convém treinar a escrever vários exemplos, porque é com a prática que o formato deixa de pesar e passa a ser natural. 🗣️ Pontos a desenvolver oralmente • Explicar a estrutura tipo, âmbito e descrição • Praticar escrever commits para alterações fictícias • Mencionar que ferramentas geram changelogs a partir destes commits

NOTAS DO PROFESSOR 📖 Quando ocorrem conflitos O primeiro objetivo é desdramatizar: um conflito não é um erro nem uma falha, é uma situação normal e esperada. Acontece quando duas branches alteram a mesma linha do mesmo ficheiro e o Git não consegue decidir sozinho. Convém transmitir calma, porque o pânico perante a palavra CONFLICT leva muitos iniciantes a fazer asneiras. 🗣️ Pontos a desenvolver oralmente • Tranquilizar a turma de que conflitos são normais • Explicar a condição exata em que surgem • Provocar deliberadamente um conflito controlado para demonstrar

NOTAS DO PROFESSOR 📖 Resolver conflitos A chave para resolver conflitos é perceber os marcadores que o Git insere no ficheiro e separar as duas versões. Convém demonstrar passo a passo: decidir o que manter, apagar todos os marcadores e só depois adicionar e fazer commit. Esquecer de remover os marcadores é o erro mais comum, e vale a pena avisar disso explicitamente. 🗣️ Pontos a desenvolver oralmente • Explicar o significado de cada marcador de conflito • Demonstrar a edição manual escolhendo ou combinando versões • Avisar que é preciso apagar todos os marcadores antes de fazer commit

NOTAS DO PROFESSOR 📖 Estratégias de resolução Para além da edição manual, há atalhos úteis quando se quer ficar com uma versão inteira: ours e theirs. A rede de segurança mais importante é o merge --abort, que permite recuar e começar de novo sem medo. Convém recomendar as ferramentas visuais, que tornam a resolução de conflitos muito mais intuitiva para iniciantes. 🗣️ Pontos a desenvolver oralmente • Explicar quando usar ours ou theirs em vez de editar à mão • Apresentar o merge --abort como botão de pânico seguro • Demonstrar a resolução de conflitos na interface do editor

NOTAS DO PROFESSOR 📖 Boas práticas de commits Esta lista de fazer e não fazer condensa anos de experiência de equipas. O princípio mais importante é o commit atómico: cada commit deve ter um único propósito claro, o que facilita reverter ou perceber a história depois. Convém insistir que "fix" como mensagem é inútil e que nunca se deve comprometer código que não compila. 🗣️ Pontos a desenvolver oralmente • Explicar o que torna um commit verdadeiramente atómico • Mostrar maus exemplos reais de mensagens vagas • Reforçar o hábito de commits frequentes em vez de gigantes

NOTAS DO PROFESSOR 📖 Boas práticas de branches Branches devem ter vida curta e nomes que digam o que contêm, como feature/add-login. O problema das branches eternas é que acumulam divergência da main e tornam o merge cada vez mais doloroso. Convém recomendar sincronizar com a main regularmente e apagar a branch logo após o merge, mantendo o repositório limpo. 🗣️ Pontos a desenvolver oralmente • Mostrar convenções de nomes claros com prefixos como feature e fix • Explicar porque branches de vida longa geram conflitos maiores • Reforçar o hábito de sincronizar com a main com frequência

NOTAS DO PROFESSOR 📖 Boas práticas de pull requests A regra prática mais valiosa é manter os PRs pequenos, idealmente abaixo de algumas centenas de linhas. Um PR gigante ninguém revê com atenção, e a revisão torna-se uma aprovação cega. Convém condenar o self-merge sem revisão, porque elimina a própria razão de ser do pull request, que é o segundo par de olhos. 🗣️ Pontos a desenvolver oralmente • Explicar porque PRs grandes recebem revisões piores • Insistir na descrição completa que contextualiza a mudança • Discutir por que o self-merge sem revisão é má prática

NOTAS DO PROFESSOR 📖 Segurança no Git Este é talvez o slide mais importante da unidade em termos de consequências reais. Comprometer uma password ou chave de API num repositório, mesmo privado, é um incidente sério. O ponto crucial é o procedimento de reação: se aconteceu, revogar a chave imediatamente, porque limpar o histórico não basta, já que o segredo pode ter sido copiado. 🗣️ Pontos a desenvolver oralmente • Insistir na regra absoluta de nunca comprometer segredos • Explicar a combinação de .env com .gitignore como prevenção • Detalhar o procedimento de emergência: revogar antes de limpar