Git na Escola: o Fluxo Real de Colaboração que Transforma Alunos em Desenvolvedores

Git na Escola: O Fluxo Real de Colaboração que Transforma Alunos em Desenvolvedores

Desenvolvimento de Sistemas — Git e GitHub

Como estruturar um ciclo completo de versionamento colaborativo — branch, pull request, code review e merge — dentro de uma aula de Ensino Médio Técnico.

Prof. Vanderli Com IA Curso Técnico em Desenvolvimento de Sistemas Educação Pública — Ensino Médio

O que é o fluxo colaborativo Git/GitHub?

O fluxo colaborativo Git/GitHub é um processo estruturado de desenvolvimento em equipe no qual cada contribuição passa por criação de branch isolada, ciclo de commits, abertura de pull request, revisão por par e merge controlado na branch principal.

Em menos de 40 palavras: um protocolo de trabalho que separa o desenvolvimento individual do código compartilhado, garantindo que nenhuma modificação chegue à base principal sem revisão consciente.

Contexto educacional Nos cursos técnicos de Desenvolvimento de Sistemas, esse fluxo não é um conteúdo avançado — é o conteúdo fundamental. Um aluno que termina o curso sem ter operado um PR real saiu sem a competência central do trabalho colaborativo em software.

Por que esse fluxo precisa ser ensinado na escola, não no mercado?

A maioria dos professores ensina os comandos Git de forma linear e individual: git init, git add, git commit. Isso é necessário, mas insuficiente. O que forma o desenvolvedor não é a sintaxe — é a prática do trabalho assíncrono com controle de qualidade.

Quando o aluno trabalha só, ele nunca precisa abrir um PR. Nunca recebe um “Changes requested”. Nunca precisa refatorar um código que já considerava pronto. O fluxo colaborativo força precisamente essas situações — e é nelas que o aprendizado real acontece.

“PR não é entrega — é pedido de validação.”

Essa distinção muda o posicionamento cognitivo do aluno. Quando ele entende que o pull request não encerra o ciclo, mas abre um diálogo técnico, ele passa a tratar o código como algo vivo, iterável e público — não como um arquivo entregue e esquecido.

Fundamento conceitual: o que está em jogo além da sintaxe

O fluxo Git/GitHub articula três camadas de aprendizagem simultâneas:

Camada	O que desenvolve	Mecanismo no fluxo
Técnica	Comandos Git, versionamento, branches	Execução dos ciclos commit → push → PR
Colaborativa	Comunicação técnica, revisão de código	Code review com comentários estruturados
Cognitiva	Iteração, aceitar feedback, refatoração	Ciclos de “Changes requested” → correção

A camada cognitiva é a mais negligenciada e a mais importante. Ela não aparece nos tutoriais de Git — aparece só quando há um outro humano revisando o código e apontando o que precisa mudar.

O ciclo completo em sala: 18 etapas comentadas

O cenário a seguir usa dois papéis fixos: Professor como mantenedor do repositório e Aluno como contribuidor. O projeto é um sistema simples de reserva de laboratório.

Fase 1 — Preparação do ambiente

Professor — Criação do repositório
No GitHub, cria o repositório lab-reserva como público, com README inicializado. Esse é o repositório-base — a fonte oficial do projeto.
Aluno — Clone do repositório
Executa o clone no terminal local. A partir daqui, o aluno tem uma cópia sincronizável do projeto.

Terminal — Aluno

git clone https://github.com/vanderli/lab-reserva.git
cd lab-reserva

Variações importantes do git clone git clone -b main <url> — clona uma branch específica
git clone <url> nome-pasta — define o nome da pasta local

Fase 2 — Desenvolvimento isolado

Aluno — Criação de branch
Antes de qualquer alteração, o aluno cria uma branch com nome descritivo. Nunca desenvolve diretamente na main.

Terminal — Aluno

# Criar e entrar na branch
git checkout -b feature/reserva-fernando

# Alternativa moderna (Git 2.23+)
git switch -c feature/reserva-fernando

# Listar branches existentes
git branch

Aluno — Desenvolvimento no VS Code
Cria index.html e script.js. Neste ciclo, o código contém um erro intencional que será capturado no code review.

script.js — versão com erro

// ❌ ERRADO: inserindo string diretamente no DOM
lista.appendChild(nome);

Aluno — Ciclo Git local
Verifica status, prepara arquivos para commit e registra o estado do código com mensagem descritiva.

Terminal — Aluno

git status
git add .
git commit -m "feat: sistema inicial de reserva"

Variações do git add e commit git add arquivo.js — adiciona arquivo específico
git restore arquivo.js — descarta alterações locais
git diff — visualiza mudanças antes de adicionar
git commit --amend — edita a mensagem do último commit

Fase 3 — Envio e abertura do pull request

Aluno — Push da branch
Envia a branch para o repositório remoto no GitHub.

Terminal — Aluno

# Primeira vez na branch
git push -u origin feature/reserva-fernando

# Pushes seguintes
git push origin feature/reserva-fernando

Atenção — git push –force O --force sobrescreve o histórico remoto sem aviso. Em projetos colaborativos, seu uso indiscriminado destrói trabalho de outros. Ensine essa opção com o aviso explícito de que ela existe para situações específicas e controladas — nunca como atalho para “resolver” conflitos.

Aluno — Abertura do PR no GitHub
No GitHub, clica em “Compare & Pull Request”. Define a base como main e a comparação como feature/reserva-fernando. Adiciona título e descrição do que foi desenvolvido.

Fase 4 — Code review e ciclos de correção

Professor — Revisão na aba Files Changed
Analisa cada linha modificada. Identifica o erro no appendChild e deixa um comentário técnico objetivo diretamente no código.

Comentário do professor no PR

“Você está inserindo uma string diretamente como nó filho do DOM. O método appendChild espera um nó — não um valor primitivo. O correto é criar um elemento <li>, definir seu textContent e então inseri-lo na lista.”

Após o comentário, o professor seleciona “Request changes” — não “Approve”. O PR permanece aberto e sinalizado como pendente de correção.

Aluno — Leitura do feedback e correção
O aluno visualiza o status “Changes requested” no PR. Corrige o código localmente, realiza novo commit na mesma branch e faz push.

script.js — versão corrigida

// ✅ CORRETO: criando elemento DOM antes de inserir
const item = document.createElement("li");
item.textContent = nome;
lista.appendChild(item);

Terminal — Aluno

git add .
git commit -m "fix: corrigido append na lista"
git push origin feature/reserva-fernando

O GitHub atualiza automaticamente o PR existente com o novo commit. O professor não precisa criar um novo processo de revisão — o histórico fica registrado dentro do mesmo pull request.

Professor — Segunda revisão
O erro está corrigido. O professor adiciona um comentário sugerindo melhoria: validação de input vazio. Neste ponto, há duas opções de conduta pedagógica.

Abordagem	Ação no PR	Quando usar
Mais rigorosa	Request changes novamente	A melhoria é obrigatória para o projeto funcionar corretamente
Mais flexível	Approve + comentário opcional	A melhoria é desejável, mas não bloqueia o merge

Fase 5 — Merge e sincronização

Aluno — Nova correção: validação de input
Implementa a verificação de campo vazio, faz commit e push.

script.js — validação adicionada

if (nome === "") {
  alert("Digite um nome válido.");
  return;
}

Professor — Aprovação final
Seleciona “Review changes → Approve → Submit review”. O PR está aprovado.
Professor — Merge
Executa o merge pelo botão “Merge pull request”. O código do Fernando entra na branch main com histórico completo do processo.

Estratégias de merge disponíveis Create merge commit — preserva o histórico completo da branch. Recomendado para projetos educacionais onde o processo importa tanto quanto o resultado.

Squash and merge — comprime todos os commits da branch em um único. Útil quando o histórico tem muitos commits intermediários.

Rebase and merge — reaplica os commits da branch sobre a main, gerando um histórico linear. Mais avançado; introduzir depois de dominado o fluxo básico.

Aluno — Sincronização local
Após o merge, o aluno precisa atualizar sua main local para refletir o estado atual do repositório remoto.

Terminal — Aluno

git checkout main
git pull origin main

Aluno — Limpeza e nova feature
Deleta a branch local que já foi mergeada e inicia uma nova branch para a próxima funcionalidade. O ciclo recomeça.

Terminal — Aluno

# Deletar branch local já mergeada
git branch -d feature/reserva-fernando

# Iniciar nova feature
git checkout -b feature/historico-reservas

Visão global do processo

Professor cria base → Aluno clona → Cria branch

↓

Desenvolve → Commit + Push → Abre PR

↓

Professor revisa → Pede correção → Aluno corrige

↓

Professor aprova → Merge na main → Nova feature

Onde os alunos erram — e como antecipar

O mapeamento de erros recorrentes em sala é parte do planejamento pedagógico. Estes são os padrões mais frequentes:

Erros típicos

Fazer commit diretamente na main
Não executar git pull antes de iniciar nova branch
Abrir novo PR em vez de corrigir o existente
Não compreender o status “Changes requested”
Usar mensagens de commit genéricas ou vazias

Como antecipar

Configurar proteção de branch na main no GitHub
Criar checklist de início de aula com os comandos obrigatórios
Demonstrar ao vivo o que acontece ao abrir dois PRs conflitantes
Projetar o PR na tela e ler os comentários em conjunto
Adotar Conventional Commits como padrão da turma

O erro mais custoso: commit na main É possível proteger a branch main em repositórios públicos e privados no GitHub, exigindo PR para qualquer alteração. Configure isso antes de iniciar a atividade — é mais eficaz do que instruir verbalmente.

Caso real: sistema de reserva de laboratório

Aplicação em sala — Ensino Médio Técnico

Contexto: Turma do 2.º ano do curso técnico em Desenvolvimento de Sistemas. Projeto integrador semestral: sistema de reserva de laboratório de informática para uso interno da escola.

Estrutura: Professor mantém o repositório principal. Cada aluno ou dupla trabalha em features independentes: tela de reserva, validação de conflitos, histórico, exportação de dados.

Resultado pedagógico observado: A partir do segundo ciclo de PR, os alunos passam a reler o próprio código antes de enviar, antecipando os comentários do professor. Esse comportamento — revisão prévia à entrega — é exatamente o hábito profissional que o fluxo precisa formar.

Produto real: O sistema, após múltiplos ciclos de review e merge, pode ser efetivamente implantado na escola. O aluno sai com um repositório público documentado, com histórico de commits, PRs e comentários — um portfólio funcional.

Expansão estratégica: o que esse fluxo pode se tornar

O fluxo Git/GitHub em sala não é um exercício isolado. É a base de uma série de possibilidades de médio e longo prazo:

Portfólio público: cada aluno constrói um GitHub com histórico real de desenvolvimento colaborativo — diferencial direto em processos seletivos.
Contribuição a projetos externos: o mesmo fluxo é idêntico ao usado em projetos open source. O aluno formado nesse ciclo está apto a abrir seu primeiro PR em um repositório público.
Produto escolar implantável: projetos desenvolvidos com esse fluxo têm estrutura suficiente para uso real dentro da escola — agenda, sistema de chamada, reserva de salas, entre outros.
Documentação do processo como ativo pedagógico: o histórico de PRs e comentários de code review pode ser publicado como estudo de caso — no blog do professor, em comunicações institucionais ou em apresentações em eventos de educação.
Formação de pares revisores: em turmas maiores, o papel de revisor pode ser rotacionado entre alunos — ampliando o repertório de quem revisa e de quem é revisado.

Perguntas frequentes em sala

Por que não posso commitar direto na main?

A main é o estado oficial do projeto — o que está lá funciona. Commitar direto nela significa introduzir código não revisado em produção. Branches isolam o risco: se a feature quebrar, apenas aquela branch é afetada, não o projeto inteiro.

Qual a diferença entre git fetch e git pull?

O git fetch baixa as atualizações do repositório remoto, mas não as aplica no branch local — permite inspecionar antes de integrar. O git pull faz o fetch e o merge em uma única operação. Para iniciantes, git pull é suficiente. O fetch é útil quando se quer verificar o que mudou antes de decidir como integrar.

O que acontece se dois alunos modificarem o mesmo arquivo?

Git vai identificar um conflito de merge. As linhas conflitantes ficam marcadas no arquivo e precisam ser resolvidas manualmente antes do merge. É um excelente momento pedagógico — ensina que colaboração requer comunicação prévia sobre quem modifica o quê.

Posso ter mais de um PR aberto ao mesmo tempo?

Sim — desde que cada PR parta de uma branch diferente. O problema surge quando um PR depende de alterações de outro ainda não mergeado. Essa situação, chamada de dependência de PRs, é um padrão que deve ser evitado em estágios iniciais de aprendizagem.

O que é Squash and merge e quando devo usar?

Squash condensa todos os commits de uma branch em um único commit antes do merge. É útil quando o histórico da branch tem commits muito granulares ou mensagens confusas geradas durante o desenvolvimento. Para fins educacionais, o merge commit padrão preserva o histórico completo — o que é mais valioso como evidência de processo.

Como nomear branches corretamente?

O padrão mais adotado é tipo/descricao-curta. Os tipos mais comuns são feature/ para novas funcionalidades, fix/ para correções e refactor/ para melhorias sem mudança de comportamento. Exemplo: feature/historico-reservas. Nomes descritivos tornam a revisão mais rápida e o histórico mais legível.

Aplique esse fluxo no próximo projeto da sua turma

O conteúdo deste artigo está em uso no Laboratório de Educação Digital. Se você é professor de curso técnico ou de disciplinas de tecnologia, acompanhe os registros do processo, os materiais e os projetos desenvolvidos pelos alunos nos canais abaixo.

professorcomia.com.br diariodeumpoed.com.br

Conclusão: o fluxo é o currículo

Ensinar Git não é ensinar comandos. É ensinar um protocolo de trabalho colaborativo que estrutura como o conhecimento técnico circula, é revisado e melhora ao longo do tempo.

O aluno que passa por dez ciclos reais de branch → commit → PR → review → correção → merge sai com algo que nenhum tutorial entrega sozinho: a experiência de ter o próprio código devolvido com comentários técnicos e a capacidade de transformar crítica em melhoria concreta.

Essa competência — iterar sob revisão — é a mais próxima do trabalho real em qualquer equipe de desenvolvimento. E ela só se forma quando o fluxo é praticado integralmente, com papéis reais, código real e consequências reais sobre o projeto.

Mudança de mentalidade O repositório do projeto não é um diretório de arquivos. É um registro de processo — quem escreveu o quê, quem revisou, o que foi corrigido e por quê. Quando o aluno compreende isso, ele passa a usar o Git como instrumento de comunicação técnica, não apenas de backup.