Pular para conteúdo

Versionamento com Git e GitHub

"O controle de versão é a base de qualquer projeto de software moderno. Sem ele, não há colaboração, sem colaboração, não há evolução." — Provérbio Dev

🧭 Atalhos Rápidos

  • Aulas --- 16 aulas completas organizadas em 4 módulos práticos. Ver Trilha

  • Slides --- Slides interativos em Reveal.js para acompanhar cada aula. Acessar Slides

  • Quizzes --- Teste seus conhecimentos com quizzes interativos interativos. Fazer Quizzes

  • Projetos --- Projetos práticos para construir seu portfólio no GitHub. Ver Projetos

  • Exercícios --- Pratique com exercícios focados em comandos reais de terminal. Praticar Agora

  • Setups --- Guias de instalação do Git e configuração de identidade. Configurar Ambiente

🗺️ Mapa da Jornada

O curso está estruturado para levar você do zero ao domínio da colaboração profissional:

  • Módulo 1 – Conceitos Básicos: Introdução ao Git, instalação, primeiros comandos e fluxo local.
  • Módulo 2 – Trabalhando com GitHub: Repositórios remotos, conexão SSH/HTTPS e colaboração em equipe.
  • Módulo 3 – Fluxos e Organização: Pull Requests, Code Review, Issues e organização de projetos.
  • Módulo 4 – Colaboração e Carreira: Boas práticas de commit, portfólio no GitHub e mercado de trabalho.

💡 Dicas de Sucesso

  1. Terminal é seu amigo: Git se aprende digitando. Evite interfaces gráficas no início.
  2. Commits pequenos e frequentes: Salve seu progresso em pedaços lógicos e explicativos.
  3. Leia as mensagens de erro: O Git geralmente diz exatamente o que fazer no terminal.

Pronto para começar? Ir para Aula 01

Plano de Ensino 🧭

Curso: Git e GitHub
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Git e GitHub.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 O que é Controle de Versão e por que usar Git? Teoria, Prática Guiada, Quiz e Exercícios
02 Instalando e Configurando o Git Teoria, Prática Guiada, Quiz e Exercícios
03 Repositórios, Commits e Histórico Teoria, Prática Guiada, Quiz e Exercícios
04 Branches e Merges: As Linhas do Tempo Teoria, Prática Guiada, Quiz e Exercícios
05 Resolução de Conflitos: O Dilema da Escolha Teoria, Prática Guiada, Quiz e Exercícios
06 Introdução ao GitHub: Sua Casa na Nuvem Teoria, Prática Guiada, Quiz e Exercícios
07 Repositórios Remotos: Conectando-se ao Mundo Teoria, Prática Guiada, Quiz e Exercícios
08 Pull Requests e Code Review: O Coração da Colaboração Teoria, Prática Guiada, Quiz e Exercícios
09 Fluxo de Trabalho: GitHub Flow Teoria, Prática Guiada, Quiz e Exercícios
10 Issues e Projetos: Organizando o Caos Teoria, Prática Guiada, Quiz e Exercícios
11 Boas Práticas: A Arte do Commit Teoria, Prática Guiada, Quiz e Exercícios
12 Documentação: README Profissional e Markdown Teoria, Prática Guiada, Quiz e Exercícios
13 Trabalho em Equipe: Colaboração Profissional Teoria, Prática Guiada, Quiz e Exercícios
14 GitHub Pages: Seu Portfólio Online Teoria, Prática Guiada, Quiz e Exercícios
15 Troubleshooting: Erros Comuns e Soluções Teoria, Prática Guiada, Quiz e Exercícios
16 Carreira, Portfólio e Próximos Passos Teoria, Prática Guiada, Quiz e Exercícios
17 Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) Teoria, Prática Guiada, Quiz e Exercícios
18 Resolução de Conflitos Complexos e Rebasing Interativo Teoria, Prática Guiada, Quiz e Exercícios
19 Automação com Git Hooks e Assinatura de Commits Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Fluxo Autônomo de Integração e Colaboração Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Git e GitHub.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado em 5 módulos estruturados.

📚 Módulos do Curso

Aula 01 – O que é Controle de Versão e por que usar Git?

🎯 Objetivos de Aprendizagem

  • Entender o conceito de Controle de Versão e sua importância no desenvolvimento.
  • Diferenciar Git (software) de GitHub (plataforma).
  • Compreender a diferença entre sistemas centralizados e distribuídos.
  • Conhecer a história e a popularidade do Git no mercado de TI.

📚 Conteúdo

1. O Problema do "Versão Final.doc"

Você já trabalhou em um arquivo importante e acabou criando cópias como tcc_final.doc, tcc_final_v2.doc ou tcc_final_IMPRIMIR.doc? Isso é controle de versão manual e é extremamente propenso a falhas: você perde o histórico de quem mudou o quê, quando e por quê.

Atenção

O controle manual de arquivos não escala. Em equipes profissionais, perder o rastro de uma alteração pode significar horas de trabalho perdido.

2. O que é um Sistema de Controle de Versão (VCS)?

Um Version Control System (VCS) é um software que rastreia mudanças em arquivos ao longo do tempo. Ele funciona como uma "Máquina do Tempo" para o seu código.

Conceito

Um VCS permite que você reverta arquivos para estados anteriores, compare mudanças entre versões e recupere arquivos perdidos acidentalmente.

3. Sistemas Centralizados vs. Distribuídos

Existem dois tipos principais de arquitetura para controle de versão:

graph TD
    subgraph "Centralizado (ex: SVN)"
        C1[Servidor Central] --- A1[Usuário A]
        C1 --- B1[Usuário B]
    end
    subgraph "Distribuído (ex: Git)"
        S2[Servidor Central] --- U1[Repositório Local A]
        S2 --- U2[Repositório Local B]
        U1 ---|Offline| U1
        U2 ---|Offline| U2
    end
  • Centralizado: Existe um único servidor que guarda o histórico. Se o servidor cair, ninguém consegue trabalhar.
  • Distribuído: Cada desenvolvedor possui uma cópia completa do histórico em sua máquina. O servidor central serve apenas como ponto de sincronização.

4. Git vs GitHub: Não Confunda!

É a dúvida mais comum para quem está começando:

Característica Git GitHub
O que é? Software de controle de versão (local). Plataforma de hospedagem na nuvem.
Instalação Instalado no seu computador. Acessado via navegador.
Função Gerencia o histórico de arquivos. Facilita a colaboração e redes sociais.

Dica

Pense no Git como o motor (software) e no GitHub como a concessionária (onde você guarda e exibe seus carros).

5. Verificação Inicial do Ambiente

Antes de começarmos a codar, vamos verificar se você já tem a ferramenta instalada.

# Verificando a versão do Git instalada
$ git --version
git version 2.45.0.windows.1

# Verificando se o comando 'git' é reconhecido
$ where git
C:\Program Files\Git\cmd\git.exe

📝 Prática

Exercícios de Fixação

O conteúdo prático desta aula foca na compreensão teórica e verificação de ambiente. Ver Exercícios da Aula 01

Mini-Projeto

Construiremos um Portfólio Profissional ao longo deste curso. O primeiro passo é apenas organizativo. Ver Projeto da Aula 01

Aula 02 – Instalando e Configurando o Git

🎯 Objetivos de Aprendizagem

  • Instalar o Git no seu sistema operacional (Windows, Mac ou Linux).
  • Configurar sua identidade global (nome e e-mail).
  • Verificar e validar a instalação e o ambiente.
  • Entender a importância da configuração de autoria.

📚 Conteúdo

1. Preparando o Ambiente

Para começar a usar o Git, precisamos de duas coisas: a ferramenta instalada e uma identidade configurada.

flowchart LR
    A[Download] --> B[Instalação]
    B --> C[Terminal / Git Bash]
    C --> D[Configurar Nome]
    D --> E[Configurar Email]
    E --> F[Validar! OK]

Windows

  • Acesse git-scm.com e baixe a versão para Windows.
  • No instalador: mantenha o padrão (Vim) ou selecione VS Code se preferir.
  • Dica: No Windows, sempre use o Git Bash que vem junto na instalação. Ele emula um terminal Linux/Unix robusto.

macOS

  • Instale via Homebrew: brew install git.
  • Ou baixe o instalador no site oficial.

Linux (Ubuntu/Debian)

  • Execute: sudo apt-get update && sudo apt-get install git-all.

2. Configuração de Identidade (Obrigatória)

O Git registra quem fez cada alteração. Sem isso, você não consegue fazer "commits".

Configuração Global

As configurações abaixo precisam ser feitas apenas uma vez no seu computador.

# Configure seu nome profissional
$ git config --global user.name "Seu Nome Completo"

# Configure seu e-mail (prefira o mesmo do GitHub)
$ git config --global user.email "seu.email@exemplo.com"

Dica de Ouro

Use o e-mail que você pretende usar na sua conta do GitHub para que seu gráfico de contribuições ("paredão verde") seja contabilizado corretamente.

3. Onde as configurações ficam salvas?

O Git guarda essas informações em um arquivo chamado .gitconfig na sua pasta de usuário (HOME).

Verificando tudo

Para listar todas as configurações ativas e confirmar se seu nome e e-mail estão corretos, use: 

$ git config --list
user.name=Seu Nome Completo
user.email=seu.email@exemplo.com
core.editor=vim

📝 Prática

Exercícios de Fixação

Coloque a mão na massa instalando e configurando sua máquina. Ver Exercícios da Aula 02

Mini-Projeto

Garantindo que sua pasta de portfólio está pronta para o terminal. Ver Projeto da Aula 02

Aula 03 – Repositórios, Commits e Histórico

🎯 Objetivos de Aprendizagem

  • Iniciar um repositório Git do zero (git init).
  • Compreender as três áreas fundamentais do Git: Working Directory, Staging Area e Repository.
  • Realizar seu primeiro commit e entender o fluxo de salvamento.
  • Visualizar e interpretar o histórico de mudanças (git log).
  • Utilizar o git status como ferramenta constante de diagnóstico.

📚 Conteúdo

1. Inicializando um Repositório

Para que o Git comece a rastrear uma pasta, precisamos "inicializá-la".

Comando Mestre

O comando git init cria uma pasta oculta chamada .git. É ali que o Git armazena todo o histórico de versões. Nunca delete essa pasta, ou você perderá o histórico do projeto!

# Transformando a pasta atual em um repositório
$ git init
Initialized empty Git repository in C:/.../.git/

2. O Modelo Mental das 3 Áreas

O Git não salva tudo automaticamente. Você precisa decidir o que salvar em um processo de 3 etapas:

graph LR
    A[Working Directory] -- "git add" --> B[Staging Area]
    B -- "git commit" --> C[Local Repository]
    style B fill:#f9f,stroke:#333,stroke-width:2px
  1. Working Directory: Onde você cria e edita seus arquivos (sua pasta de projeto).
  2. Staging Area (Index): Uma zona de preparação. Pense nela como uma "caixa" onde você coloca os itens que quer enviar no próximo commit.
  3. Repository: O "banco de dados" de versões. Quando você faz um commit, o conteúdo da Staging Area é gravado permanentemente aqui.

3. O Fluxo de Trabalho Básico

O ciclo de vida de uma alteração segue sempre este padrão:

Comando de Ouro: git status

Use o git status o tempo todo! Ele diz em qual área seus arquivos estão e sugere os próximos comandos.

# 1. Veja o estado atual
$ git status

# 2. Adicione ao Staging Area (prepair para o commit)
$ git add arquivo.txt

# 3. Grave a versão com uma mensagem explicativa
$ git commit -m "Explicação curta do que foi feito"

4. Consultando o Passado: git log

Como saber o que foi feito ontem? Ou por quem?

$ git log
commit a1b2c3d4... (HEAD -> main)
Author: Ricardo Tec Pro <ricardotecpro@hotmail.com>
Date:   Thu Feb 26 17:15:00 2026 -0300

    Adiciona arquivo sobre mim

Conceito Chave

Um Commit é como uma fotografia (snapshot) do seu projeto naquele exato momento. Ele possui um ID único (Hash) que permite voltar no tempo sempre que necessário.

📝 Prática

Exercícios de Fixação

Pratique os primeiros comandos em um ambiente seguro. Ver Exercícios da Aula 03

Mini-Projeto

Chegou a hora de dar o "primeiro passo" oficial no seu portfólio. Ver Projeto da Aula 03

Aula 04 – Branches e Merges: As Linhas do Tempo

🎯 Objetivos de Aprendizagem

  • Entender o conceito de Branches (Ramificações) como isolamento de trabalho.
  • Criar, listar e navegar entre branches utilizando git branch e git switch.
  • Realizar a fusão de alterações de diferentes linhas do tempo com git merge.
  • Compreender a segurança de trabalhar em "funcionalidades isoladas".

📚 Conteúdo

1. O Conceito de "Multiverso" no Git

Imagine que você tem um jogo funcional (branch main). Você quer testar uma "fase de gelo", mas não quer estragar a versão estável se algo der errado. No Git, você cria um Branch.

Definição

Um branch é um ponteiro móvel para um commit. Ele permite que você saia da linha principal, faça experimentos e depois decida se quer incorporá-los ou descartá-los.

2. O Fluxo de Ramificação

gitGraph
    commit
    commit
    branch feature-gelo
    checkout feature-gelo
    commit
    commit
    checkout main
    merge feature-gelo
    commit

3. Comandos de Navegação

Cuidado com o Trabalho Sujo

Sempre faça commit ou "stash" (veremos adiante) das suas mudanças antes de trocar de branch, para evitar conflitos de arquivos.

# Listar todos os branches locais
$ git branch
* main

# Criar um novo branch (ex: para uma nova funcionalidade)
$ git branch feature-contato

# Tocar para o novo branch
$ git switch feature-contato
Switched to branch 'feature-contato'

4. Unindo Mundos: O Merge

Após terminar o trabalho na sua branch isolada, você deve trazer essas novidades para a branch principal.

# 1. Volte para a branch que vai RECEBER as mudanças
$ git switch main

# 2. Execute o merge
$ git merge feature-contato
Updating a1b2c3d..e4f5g6h
Fast-forward
 contato.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 contato.txt

Boas Práticas

Nunca trabalhe diretamente na main. Crie uma branch para cada nova tarefa. Isso mantém o código estável sempre disponível para "produção".

📝 Prática

Exercícios de Fixação

Experimente criar e unir diferentes linhas do tempo. Ver Exercícios da Aula 04

Mini-Projeto

Adicionando novas funcionalidades ao seu portfólio de forma segura através de branches. Ver Projeto da Aula 04

Aula 05 – Resolução de Conflitos: O Dilema da Escolha

🎯 Objetivos de Aprendizagem

  • Entender o que é um conflito de merge (Merge Conflict).
  • Identificar por que conflitos acontecem e como o Git os detecta.
  • Aprender a ler e interpretar os marcadores de conflito (<<<<<<<, =======, >>>>>>>).
  • Resolver conflitos manualmente através do terminal ou editor de código.

📚 Conteúdo

1. O que é um Conflito?

O Git é excelente em unir alterações automaticamente. Se você altera o cabeçalho e um colega altera o rodapé, o git merge faz o trabalho sozinho. Porém, se ambos alterarem a mesma linha de formas diferentes, o Git entra em "segurança": ele para o processo e pergunta: "Quem está certo?".

graph TD
    A[Commit Inicial] --> B[Branch A: Título Vermelho]
    A --> C[Branch B: Título Azul]
    B --> D{TENTATIVA DE MERGE}
    C --> D
    D --> E[CONFLITO!]

O Conflito é um Recurso

O conflito não é um erro do sistema, mas um mecanismo de segurança para evitar que o Git apague o trabalho de alguém sem supervisão humana.

2. Anatomia de um Conflito

Quando o conflito acontece, o Git modifica o arquivo e adiciona marcadores visuais.

Identificando Marcadores

O arquivo ficará assim até você editá-lo: 

<<<<<<< HEAD
Meu título é Incrível! (Sua versão atual)
=======
Este título é Fantástico! (Versão que está chegando)
>>>>>>> branch-do-colega

3. Como Resolver: O Passo a Passo

A resolução é um processo manual e envolve 3 etapas fundamentais:

# 1. Identifique os arquivos com conflito
$ git status
both modified:   arquivo.txt

# 2. Abra o arquivo no seu editor, escolha a versão final e APAGUE os marcadores (<<<<, ====, >>>>)

# 3. Marque como resolvido
$ git add arquivo.txt

# 4. Finalize o merge
$ git commit

Dica de Ouro

Muitas vezes, a melhor solução não é escolher uma ou outra versão, mas sim criar uma terceira versão que combine as ideias de ambas as partes. Comunique-se com seu time!

📝 Prática

Exercícios de Fixação

Enfrente seu primeiro conflito em um ambiente controlado e seguro. Ver Exercícios da Aula 05

Mini-Projeto

Simulando um conflito no seu portfólio para dominar a resolução manual. Ver Projeto da Aula 05

Aula 06 – Introdução ao GitHub: Sua Casa na Nuvem

🎯 Objetivos de Aprendizagem

  • Navegar pela interface do GitHub e entender suas seções principais.
  • Configurar um perfil profissional atrativo para recrutadores.
  • Entender conceitos sociais: Stars, Forks, Watch e Issues.
  • Diferenciar repositórios públicos de privados.

📚 Conteúdo

1. O GitHub como seu Currículo Vivo

Diferente de um currículo em papel, o GitHub prova o que você sabe fazer através do código real.

graph LR
    A[Perfil do Dev] --> B[Repositórios]
    A --> C[Contribuições]
    B --> D[Code]
    B --> E[Issues/Projetos]
    C --> F[Heatmap/Quadradinhos Verdes]

O Heatmap

O gráfico de contribuições é um dos primeiros lugares onde recrutadores olham. Ele demonstra consistência e hábito de estudo.

2. Conceitos de Interação Social

O GitHub funciona como uma rede social para desenvolvedores. Domine estas ferramentas:

  • Star (Estrela): Salva o repositório como um favorito. Ajuda o projeto a ganhar visibilidade.
  • Watch (Observar): Deixa você "inscrito" no repositório para receber notificações de mudanças.
  • Fork (Bifurcação): Cria uma cópia exata do repositório de outra pessoa na sua conta. É o primeiro passo para contribuir com projetos famosos.

3. Gestão com Issues

Issues são muito mais do que "erros". Elas são a ferramenta oficial de gestão do GitHub.

Para que usar Issues?

  • Relatar bugs (erros no código).
  • Sugerir novas funcionalidades.
  • Discutir ideias com outros desenvolvedores.
  • Organizar sua própria lista de tarefas (To-Do list).

4. Segurança e Profissionalismo

Segurança: 2FA

Ative sempre a Autenticação de Dois Fatores (2FA) em sua conta. O GitHub é um alvo comum para hackers devido ao valor do código hospedado.

Dica Profissional

Mantenha sua Bio curta e direta. Use uma foto clara e amigável. Fixe (Pin) seus melhores projetos no topo do seu perfil para causar uma boa primeira impressão.

📝 Prática

Exercícios de Fixação

Explore a interface e personalize seu perfil para o mercado. Ver Exercícios da Aula 06

Mini-Projeto

Preparação mental para a grande subida: na próxima aula, seu código ganha o mundo! Ver Projeto da Aula 06

Aula 07 – Repositórios Remotos: Conectando-se ao Mundo

🎯 Objetivos de Aprendizagem

  • Criar um novo repositório no GitHub para hospedar seu código na nuvem.
  • Conectar um repositório local a um remoto utilizando git remote add.
  • Realizar o envio de alterações para o servidor através do git push.
  • Baixar e colaborar em projetos existentes utilizando o git clone.
  • Compreender a função vital do arquivo .gitignore.

📚 Conteúdo

1. O Conceito de Repositório Remoto

Até agora, seu trabalho vive apenas no seu computador. Para colaborar ou ter um backup seguro, usamos um Remote.

graph LR
    subgraph Local [Seu Computador]
        A[Git Repo Local]
    end
    subgraph Cloud [GitHub / Nuvem]
        B[Git Repo Remoto]
    end
    A -- "git push" --> B
    B -- "git clone / pull" --> A

2. Conectando Local e Remoto

O primeiro passo é dizer ao seu Git local onde está o "balde" na nuvem.

O Apelido 'origin'

origin é apenas uma convenção. É o nome padrão que damos ao repositório principal no servidor.

# Adiciona um vínculo remoto (troque pela URL do seu repo)
$ git remote add origin https://github.com/usuario/projeto.git

# Verifica se o vínculo foi criado com sucesso
$ git remote -v
origin  https://github.com/usuario/projeto.git (fetch)
origin  https://github.com/usuario/projeto.git (push)

3. Enviando e Baixando Código

  • Push: "Empurra" seus commits para o servidor.
  • Clone: Cria uma cópia local completa de um repositório remoto pela primeira vez.

Upstream (-u)

Ao usar git push -u origin main pela primeira vez, você vincula as branches. No futuro, bastará digitar apenas git push.

# Enviando para a branch principal
$ git push -u origin main

# Clonando um projeto de outra pessoa
$ git clone https://github.com/outra-pessoa/projeto-legal.git

4. O Arquivo .gitignore

Nem tudo deve ir para o GitHub! Arquivos de configuração pessoal, senhas (.env), pastas de dependências gigantes (node_modules) ou arquivos temporários devem ser ignorados.

Segurança

Nunca coloque chaves de API ou senhas em repositórios públicos. Use o .gitignore para prevenir acidentes!

Exemplo de .gitignore: 

.env
node_modules/
*.log
.DS_Store

📝 Prática

Exercícios de Fixação

Pratique a conexão entre seu computador e a nuvem. Ver Exercícios da Aula 07

Mini-Projeto

Momento épico: suba seu portfólio para o GitHub e torne-o público! Ver Projeto da Aula 07

Aula 08 – Pull Requests e Code Review: O Coração da Colaboração

🎯 Objetivos de Aprendizagem

  • Entender o fluxo de Pull Request (PR) como pedido de inclusão de código.
  • Aprender como sugerir mudanças em projetos de forma organizada.
  • Realizar um Code Review básico focado em qualidade e aprendizado.
  • Finalizar (Merge) um PR através da interface do GitHub.

📚 Conteúdo

1. O que é um Pull Request (PR)?

Se você trabalha em branches isoladas, como avisa sua equipe que sua tarefa está pronta para entrar na branch principal (main)? Você cria um Pull Request.

Tradução

Pull Request significa, literalmente, "Pedido de Puxada". Você está pedindo para os administradores do projeto "puxarem" suas alterações para o código oficial.

2. O Ciclo de Vida do PR

sequenceDiagram
    participant D as Desenvolvedor
    participant G as GitHub (Server)
    participant R as Revisor (Time)
    D->>G: git push (nova-branch)
    D->>G: Open Pull Request
    G->>R: Notifica Revisor
    R->>G: Faz Comentários / Sugestões
    D->>G: Ajusta Código (se necessário)
    R->>G: Approve PR
    G->>G: Merge to main

3. Code Review (Revisão de Código)

É a prática de ler o código de outra pessoa antes de aceitá-lo.

Benefícios do Review

  • Qualidade: Encontra bugs antes que cheguem ao usuário final.
  • Aprendizado: O time discute melhores formas de resolver problemas.
  • Padrão: Mantém o código do projeto uniforme e legível.

Ética no Review

Lembre-se: você está revisando o código, não a pessoa. Seja educado, construtivo e elogie boas soluções!

4. Merge via Interface do GitHub

Diferente do merge local, o merge de um PR acontece no servidor do GitHub através de um botão. Após o merge, todos os outros desenvolvedores devem fazer um git pull localmente para receberem as novidades.

📝 Prática

Exercícios de Fixação

Simule a abertura e a revisão de um pedido de alteração. Ver Exercícios da Aula 08

Mini-Projeto

Integrando novas melhorias ao seu portfólio seguindo o fluxo profissional de PR. Ver Projeto da Aula 08

Aula 09 – Fluxo de Trabalho: GitHub Flow

🎯 Objetivos de Aprendizagem

  • Entender a importância de seguir um fluxo de trabalho (workflow) padronizado.
  • Aprender o GitHub Flow: um modelo ágil, leve e focado em entrega contínua.
  • Diferenciar o GitHub Flow de modelos mais complexos como o Git Flow.
  • Compreender o ciclo completo: Branch -> Commit -> PR -> Deploy -> Merge.

📚 Conteúdo

1. O que é um Workflow?

Um workflow é um conjunto de regras que a equipe combina para evitar o caos. Sem regras, o repositório se torna uma bagunça de códigos inacabados.

A Regra de Ouro

No GitHub Flow, a branch main é sagrada. Ela deve estar sempre estável e pronta para ser enviada para produção a qualquer momento.

2. Os 6 Passos do GitHub Flow

Este é o fluxo utilizado pelas empresas de tecnologia mais modernas do mundo:

graph TD
    A[main] -->|1. Criar Branch| B(feature-branch)
    B -->|2. Commits Locais| C(Desenvolvimento)
    C -->|3. Pull Request| D{4. Discussão & Review}
    D -->|Ajustes| B
    D -->|5. Deploy / Teste| E(Ambiente Temporário)
    E -->|6. Merge na main| F[DEPLOY FINAL]

3. Por que o GitHub Flow?

Diferente do Git Flow (modelo mais antigo e complexo), o GitHub Flow foca na velocidade.

Característica GitHub Flow Git Flow
Complexidade Baixa (Leve) Alta (Muitas branches)
Velocidade Entrega Contínua Lançamentos Agendados
Ideal para Web, SaaS, Apps Softwares de prateleira (OS)

4. Executando o Fluxo no Terminal

Crie Branches Descritivas

Evite nomes como branch1. Use ajusta-bug-login ou adiciona-secao-contato.

# 1. Certifique-se de estar na main e atualizado
$ git switch main
$ git pull

# 2. Crie e mude para a nova branch em um só comando
$ git switch -c feature-nova-sessao

# 3. Trabalhe, adicione e commite
$ git add .
$ git commit -m "Adiciona nova seção de biografia"

# 4. Envie para o GitHub para abrir o PR
$ git push origin feature-nova-sessao

📝 Prática

Exercícios de Fixação

Desenhe e simule o fluxo completo do GitHub Flow em sua máquina. Ver Exercícios da Aula 09

Mini-Projeto

Aplicando o GitHub Flow para evoluir seu portfólio de forma profissional. Ver Projeto da Aula 09

Aula 10 – Issues e Projetos: Organizando o Caos

🎯 Objetivos de Aprendizagem

  • Aprender a registrar e organizar tarefas de forma profissional com Issues.
  • Utilizar Labels, Assignees e Milestones para classificar e priorizar o trabalho.
  • Gerenciar o fluxo de trabalho visualmente através do GitHub Projects (Kanban).
  • Compreender a automação de fechar Issues através de Pull Requests.

📚 Conteúdo

1. Issues: A Unidade Atômica de Trabalho

No GitHub, uma "Issue" (Questão/Problema) é utilizada para registrar qualquer tipo de trabalho necessário em um repositório.

Tipos Comuns de Issues

  • Bug: Erro no código que precisa de correção.
  • Feature: Nova funcionalidade a ser desenvolvida.
  • Enhancement: Melhoria em algo que já existe.
  • Task: Tarefas administrativas ou de documentação.

2. Gestão Visual com GitHub Projects

Trabalhar em uma lista infinita de Issues é desmotivador. Por isso, usamos o GitHub Projects para transformar essas tarefas em um quadro Kanban.

graph LR
    subgraph "PROJETO KANBAN"
        T[Todo / A Fazer] --> P[In Progress / Fazendo]
        P --> D[Done / Concluído]
    end
    I1[Issue #1] --> T
    I2[Issue #2] --> T

3. Anatomia de uma Issue Profissional

Para que uma Issue seja útil, ela deve conter: - Title: Curto e objetivo. - Assignees: Quem é o responsável pela entrega? - Labels: Etiquetas coloridas para filtro rápido (ex: bug, documentation). - Milestones: "Marcos" que agrupam issues por data de entrega (ex: Versão 1.0).

4. Automação: O Truque do "Closes"

Você pode economizar tempo conectando seu código à sua tarefa.

Automação de Fechamento

Se você escrever Closes #10 (onde 10 é o número da issue) na descrição do seu Pull Request, o GitHub fechará automaticamente a Issue assim que o merge for aprovado.

# Exemplo de mensagem de commit ou descrição de PR
$ git commit -m "Refatora login e closes #45"

📝 Prática

Exercícios de Fixação

Crie, categorize e organize suas primeiras tarefas no GitHub. Ver Exercícios da Aula 10

Mini-Projeto

Construindo o "Roadmap" (Mapa de Futuro) para o seu portfólio profissional. Ver Projeto da Aula 10

Aula 11 – Boas Práticas: A Arte do Commit

🎯 Objetivos de Aprendizagem

  • Escrever mensagens de commit claras, úteis e profissionais.
  • Entender e aplicar o conceito de Commit Atômico.
  • Conhecer o padrão global Conventional Commits.
  • Evitar erros comuns como commits gigantes ou mensagens vagas.

📚 Conteúdo

1. Mensagens que Contam Histórias

Cuidado com o "Hall da Vergonha" do histórico do Git: ajuste, teste, arrumando, final_v2. Isso não ajuda ninguém. O objetivo da mensagem de commit é explicar o porquê da mudança.

❌ Ruim ✅ Bom Motivo
corrigido fix: corrige erro no login Explica o que foi feito.
mais coisas feat: adiciona botão de busca Especifica a funcionalidade.
lixo refactor: limpa código morto Indica uma melhoria técnica.

A Regra do Imperativo

Escreva a mensagem como se estivesse dando uma ordem ao código: "Adiciona botão", "Remove ícone", "Corrige bug".

2. Commits Atômicos: O Superpoder da Reversão

Um commit deve fazer uma única coisa. Se você corrigiu um erro no rodapé e mudou a cor do cabeçalho, faça dois commits separados.

Commit Gigante

Misturar assuntos dificulta o Code Review e torna quase impossível reverter apenas uma parte da mudança se algo der errado.

3. Conventional Commits

Este é o padrão de mercado usado por grandes empresas e projetos Open Source:

  • feat:: Nova funcionalidade.
  • fix:: Correção de bug.
  • docs:: Alteração em documentação.
  • style:: Formatação (espaços, ponto e vírgula) sem mudar lógica.
  • refactor:: Melhoria de código que não altera o comportamento.
  • test:: Adição ou correção de testes.

4. Ops, errei a mensagem! (git commit --amend)

Cometeu um erro de digitação no último commit? Não se desespere!

# Corrigindo a mensagem do ÚLTIMO commit (antes do push)
$ git commit --amend -m "feat: adiciona busca por categorias"

Cuidado

Nunca use o --amend em commits que você já enviou para o GitHub (push), pois isso reescreve o histórico e pode causar problemas para seus colegas.

📝 Prática

Exercícios de Fixação

Refine suas mensagens e aprenda a dividir suas tarefas em pequenas entregas. Ver Exercícios da Aula 11

Mini-Projeto

Padronizando o histórico do seu portfólio com Conventional Commits. Ver Projeto da Aula 11

Aula 12 – Documentação: README Profissional e Markdown

🎯 Objetivos de Aprendizagem

  • Entender por que o README.md é o seu cartão de visitas para o mundo.
  • Aprender a sintaxe fundamental do Markdown para formatar textos.
  • Estruturar documentações atraentes e organizadas para repositórios.
  • Integrar mídias, badges e emojis para uma interface mais rica.

📚 Conteúdo

1. O Cartão de Visitas do seu Código

Quando um recrutador ou outro desenvolvedor abre seu repositório, o arquivo README.md é a primeira coisa que ele vê. Se estiver vazio ou bagunçado, o projeto inteiro será julgado da mesma forma.

O que um bom README deve responder?

  • O que é este projeto? (Contexto)
  • Para que serve? (Problema resolvido)
  • Como eu rodo isso na minha máquina? (Instrução)

2. Markdown: Simples e Poderoso

O Markdown (.md) é uma linguagem de marcação leve que permite formatar texto de maneira rápida.

Elemento Sintaxe Resultado
Títulos # H1 até ###### H6 Cabeçalhos de vários tamanhos.
Negrito **Texto** Texto
Links [Nome](URL) [Nome](URL)
Código inline ou ```bloco``` Formatação monospace.
Itens - Item ou * Item Listas com marcadores.

3. Estrutura de Documentação "Gold Standard"

Um repositório profissional geralmente segue esta ordem:

graph TD
    A[Banner/Título e Badges] --> B[Descrição Curta]
    B --> C[Status do Projeto]
    C --> D[Funcionalidades / Features]
    D --> E[Instalação e Uso]
    E --> F[Tecnologias Utilizadas]
    F --> G[Créditos e Autor]

4. Dicas Visuais: Badges e Emojis

Use emojis para dar tom e personalidade (ex: 🚀, 🐛). Use Badges (escudos decorativos) via Shields.io para mostrar a versão do projeto, linguagens usadas ou se os testes estão passando.

Exemplo de Badge

JS

📝 Prática

Exercícios de Fixação

Domine a sintaxe do Markdown e crie documentos formatados. Ver Exercícios da Aula 12

Mini-Projeto

Transformando seu portfólio de um simples arquivo de texto em uma vitrine profissional. Ver Projeto da Aula 12

Aula 13 – Trabalho em Equipe: Colaboração Profissional

🎯 Objetivos de Aprendizagem

  • Entender os níveis de permissão no GitHub (Read, Write, Admin).
  • Adicionar colaboradores a um repositório privado ou público.
  • Compreender a diferença entre Colaborador (Interno) e Contribuidor (Comunidade/Fork).
  • Simular um fluxo de trabalho em equipe e gerenciar o "Push Rejeitado".

📚 Conteúdo

1. Níveis de Permissão no GitHub

Por padrão, apenas o dono (Owner) pode alterar um repositório. Para trabalhar em grupo, você deve conceder acessos específicos:

  • Read: Pode ler o código e abrir Issues.
  • Write: Pode criar branches e dar push direto (Colaborador).
  • Admin: Pode gerenciar configurações e deletar o repositório.

2. Colaborador vs Contribuidor

Existem duas formas principais de contribuir para um projeto no GitHub:

graph TD
    subgraph "Equipe Interna (Colaboradores)"
        A[Repo Oficial] --- B[Dev A]
        A --- C[Dev B]
        B -- "Push Direto" --> A
        C -- "Push Direto" --> A
    end
    subgraph "Comunidade (Contribuidores)"
        D[Dev Externo] -- "Fork" --> E[Copia Pessoal]
        E -- "Pull Request" --> A
    end

3. A Regra de Ouro: Pull antes do Push

Quando você trabalha em equipe, o servidor pode ter commits que você ainda não tem na sua máquina. Se você tentar enviar (push) seu trabalho sem estar atualizado, o Git recusará.

Erro Comum: Updates Rejeitados

O Git impede o push para evitar que você apague acidentalmente o trabalho do seu colega que já está no servidor.

# Sincronize sempre seu código antes de começar a trabalhar
$ git pull origin main
From https://github.com/usuario/projeto
 * branch            main       -> FETCH_HEAD
Already up to date.

4. Gestão de Membros

Para adicionar alguém ao seu time: 1. Vá em Settings no repositório. 2. Acesse Collaborators. 3. Clique em Add people e digite o usuário ou e-mail.

Dica Profissional

Nunca dependa de uma única pessoa para ter permissão de Admin. Em projetos de empresa, garanta que pelo menos dois desenvolvedores seniores tenham acesso total para evitar bloqueios.

📝 Prática

Exercícios de Fixação

Simule a entrada de um colega no projeto e aprenda a lidar com repositórios compartilhados. Ver Exercícios da Aula 13

Mini-Projeto

Preparando seu portfólio para receber contribuições e exibir colaboradores. Ver Projeto da Aula 13

Aula 14 – GitHub Pages: Seu Portfólio Online

🎯 Objetivos de Aprendizagem

  • Entender o conceito de hospedagem gratuita com o GitHub Pages.
  • Transformar um repositório de código em um site acessível por qualquer pessoa.
  • Compreender as limitações técnicas de sites estáticos.
  • Publicar seu projeto de Portfólio na web.

📚 Conteúdo

1. Do Código à Web

Até agora, seu projeto vive apenas em pastas. O GitHub Pages é o serviço que permite "ligar" seus arquivos HTML, CSS e JS em um endereço real (URL).

graph LR
    A[Código Local] -- "Push" --> B[GitHub Repo]
    B -- "Settings > Pages" --> C[GitHub Actions]
    C -- "Deploy" --> D[https://usuario.github.io]

2. O que é um Site Estático?

O GitHub Pages é focado em performance e segurança, por isso ele suporta apenas conteúdo estático.

✅ Suportado (Static) ❌ Não Suportado (Dynamic/Backend)
HTML5 / CSS3 / JavaScript PHP / Python (Django/Flask)
Frameworks (React, Vue, Vite) Node.js (Servidor)
Imagens / Vídeos / SVGs Bancos de Dados (MySQL, MongoDB)

Endereço Padrão

Seu site ficará disponível no formato: https://SEU-USUARIO.github.io/NOME-DO-REPO/.

3. Requisito Vital: index.html

O servidor do GitHub busca automaticamente por um arquivo chamado index.html na raiz do seu projeto. Se ele não existir, seu site não carregará corretamente.

Atenção ao Case-Sensitive

O nome do arquivo deve ser exatamente index.html (minúsculo). Em servidores Linux (como os do GitHub), Index.html ou INDEX.HTML são arquivos diferentes e podem causar erro 404.

4. Limites de Uso

O serviço é generoso, mas possui limites para evitar abusos: - Tamanho do Site: Recomendado até 1GB. - Largura de Banda: 100GB por mês. - Builds: Limite de 10 deploys por hora.

Dica de Sucesso

Use o GitHub Pages para hospedar documentações de seus projetos, landing pages e, claro, seu portfólio de desenvolvedor. É a vitrine oficial do seu trabalho!

📝 Prática

Exercícios de Fixação

Ative seu primeiro site gratuito e teste a visualização em diferentes dispositivos. Ver Exercícios da Aula 14

Mini-Projeto

Publicando a versão final do seu portfólio para o mundo ver. Ver Projeto da Aula 14

Aula 15 – Troubleshooting: Erros Comuns e Soluções

🎯 Objetivos de Aprendizagem

  • Identificar e corrigir os erros mais frequentes do dia a dia no Git.
  • Entender o estado de Detached HEAD e como sair dele com segurança.
  • Resolver situações de commits feitos na branch errada usando git reset.
  • Recuperar arquivos deletados acidentalmente através do git restore.

📚 Conteúdo

1. Socorro, o Push foi Rejeitado!

O erro ! [rejected] main -> main (fetch first) acontece porque há commits no servidor que você não tem localmente.

Solução

Basta sincronizar seu repositório local antes de tentar enviar novamente: 

$ git pull origin main
# Resolva conflitos se surgirem, e então:
$ git push origin main

2. Desfazendo Commits com Reset

Errou a mensagem ou o conteúdo do último commit? O reset é sua ferramenta.

Tipo de Reset Comando Resultado
Soft git reset --soft HEAD~1 Desfaz o commit, mas mantém os arquivos no Stage (prontos para novo commit).
Mixed git reset HEAD~1 Desfaz o commit e tira do Stage, mas mantém as alterações nos arquivos.
Hard git reset --hard HEAD~1 Apaga tudo! Volta ao estado do commit anterior e deleta seu trabalho atual.

Cuidado com o --hard

O reset --hard é destrutivo. Use-o apenas se tiver certeza absoluta de que quer jogar seu trabalho atual fora.

3. Detached HEAD: O Limbo do Git

Acontece quando você faz checkout em um commit específico (hash) em vez de uma branch. Você "viaja no tempo", mas não está em nenhuma linha ativa.

graph LR
    A[Commit 1] --> B[Commit 2]
    B --> C[Commit 3 - HEAD]
    B -.-> D[Limbo / Detached HEAD]
    style D fill:#f66,stroke:#333

Como sair do Limbo

  • Para descartar o que viu e voltar ao normal: git switch main.
  • Para salvar o que fez no limbo em uma nova branch: git switch -c nova-branch-com-correcoes.

4. Recuperei, e agora? (git restore)

Deletou um arquivo sem querer? O Git registrou a existência dele no último commit.

# Traz o arquivo de volta do último commit para sua pasta
$ git restore arquivo.txt

📝 Prática

Exercícios de Fixação

Simule erros propositais e aprenda a consertá-los sem pânico. Ver Exercícios da Aula 15

Mini-Projeto

Limpando e organizando seu portfólio após correções de emergência e simulações de erros. Ver Projeto da Aula 15

Aula 16 – Carreira, Portfólio e Próximos Passos

🎯 Objetivos de Aprendizagem

  • Entender como o GitHub impulsiona sua visibilidade no mercado de trabalho.
  • Aprender os primeiros passos para contribuir com projetos Open Source.
  • Conhecer conceitos avançados para continuar seus estudos (CI/CD, Actions, Hooks).
  • Revisão geral das competências adquiridas durante o curso.

📚 Conteúdo

1. Sua Marca Profissional no GitHub

O GitHub é muito mais do que um repositório; é o seu currículo técnico em tempo real. Recrutadores buscam três pilares:

  • Consistência: O "paredão verde" (heatmap) demonstra hábito e disciplina de estudo.
  • Qualidade: READMEs bem escritos, código limpo e histórico de commits organizado (Conventional Commits).
  • Curadoria: O uso de "Pinned Repositories" para destacar seus melhores trabalhos no topo do perfil.

Dica de Ouro

Fixe (Pin) no máximo 6 repositórios. Escolha aqueles que você tem orgulho de explicar em uma entrevista técnica.

2. O Mundo do Open Source

Software de código aberto move o mundo. Contribuir para projetos famosos é uma das melhores formas de aprender.

  • good first issue: Label usada para marcar tarefas ideais para quem está começando.
  • Hacktoberfest: Evento anual que incentiva a primeira contribuição.

3. Próximos Passos: O Mapa de Evolução

Você dominou a base sólida. Veja o que o espera no nível intermediário/avançado:

graph TD
    A[Base Concluída: Git & GitHub] --> B[CI/CD com GitHub Actions]
    A --> C[Padrões de Trabalho: Git Flow / Trunk Based]
    B --> D[Automação de Testes e Deploy]
    C --> E[Colaboração em Larga Escala]
    A --> F[Git Hooks e Qualidade de Código]

4. Checklist do Desenvolvedor Profissional

Sempre que iniciar um novo projeto, lembre-se: 1. [] Criar um .gitignore adequado. 2. [] Seguir o GitHub Flow (sempre usar branches). 3. [] Escrever mensagens no padrão Conventional Commits. 4. [] Criar um README.md "Gold Standard". 5. [] Revisar o código (Code Review) mesmo trabalhando sozinho.

📝 Prática

Exercícios de Fixação

Faça a faxina final em seu perfil e prepare-se para ser descoberto pelo mercado. Ver Exercícios da Aula 16

Mini-Projeto

Finalizando seu Roadmap de estudos e conectando seu portfólio aos seus objetivos de carreira. Ver Projeto da Aula 16

Aula 17 - Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🌿

Objetivo Pedagógico

Objetivo: Avaliar criticamente os modelos de branching Git Flow, GitHub Flow e Trunk-Based Development, analisando impactos em integração contínua (CI), frequência de deploy e estabilidade de releases.

📑 1. Fundamentos Teóricos & Análise Técnica

Em engenharia de software contemporânea, a estratégia de ramificação de código (Branching Strategy) dita a velocidade de entrega e a cadência de integração das equipes.

A evolução dos modelos de ciclo de vida de software gerou duas abordagens paradigmáticas: 1. Git Flow (Modelo de Release Agendada): - Estrutura estrita com ramificações de longa duração: main (produção estável) e develop (integração de features). - Ramificações de suporte efêmeras: feature/* (novas funcionalidades), release/* (preparação de congelamento de código para homologação) e hotfix/* (correção emergencial em produção). - Desafios: Tende a gerar o fenômeno conhecido como Merge Hell devido a branches que divergem por semanas, retardando o feedback de testes integrados.

  1. Trunk-Based Development (TBD - Entrega Contínua de Alto Desempenho):
  2. Todos os desenvolvedores integram seu trabalho diretamente na ramificação principal (main / trunk) com altíssima frequência (múltiplas vezes ao dia).
  3. Branches de feature têm vida ultracurta (menos de 24 a 48 horas) e são pequenas o suficiente para serem revisadas rapidamente em pull requests atômicos.
  4. Feature Flags (Feature Toggles): Funcionalidades ainda em desenvolvimento são publicadas em produção desativadas por chaves lógicas, dissociando o processo de deploy físico da liberação de negócio (Release).

📐 Arquitetura Conceitual & Diagrama de Fluxo

gitGraph
    commit id: "v1.0.0"
    branch feature/nova-api
    checkout feature/nova-api
    commit id: "feat: endpoint auth"
    commit id: "test: unit tests"
    checkout main
    merge feature/nova-api id: "PR #142 (Trunk-Based Merge)"
    commit id: "deploy: deploy continuo prod"
    branch hotfix/fix-token
    checkout hotfix/fix-token
    commit id: "fix: token expirado"
    checkout main
    merge hotfix/fix-token id: "PR #143 (Hotfix)"
    commit id: "v1.0.1"

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Diferença Crítica: Deploy vs. Release: Deploy é a transferência de artefatos para servidores; Release é a ativação da funcionalidade para os usuários finais. - Feature Flags e Decoupling: Uso de flags dinâmicas para ocultar código incompleto sem interromper o fluxo contínuo de integração na branch principal. - Pull Requests Atômicos: Mudanças limitadas a poucas dezenas ou centenas de linhas de código facilitam a revisão e reduzem drasticamente riscos de regressão. - Métricas DORA (DevOps Research and Assessment): Deploy Frequency e Lead Time for Changes são diretamente favorecidos pelo modelo Trunk-Based.

🛠️ 2. Implementação Prática em Controle de Versão Distribuído e Estratégias de Branching

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// trunk_based_workflow.sh (Ciclo de Vida de Feature de Vida Curta em Trunk-Based)
#!/usr/bin/env bash
set -euo pipefail

# 1. Atualizar trunk principal
git checkout main
git pull --rebase origin main

# 2. Criar branch de vida ultracurta (< 24 horas)
BRANCH_NAME="feat/auth-rate-limit"
git checkout -b "$BRANCH_NAME"

# 3. Desenvolver alteração atômica com testes
echo "// Implementação com Feature Flag" >> auth_service.ts
git add auth_service.ts
git commit -m "feat(auth): adicionar rate limiter protegido por feature flag"

# 4. Rebase com o trunk antes de abrir o Pull Request
git fetch origin main
git rebase origin/main

# 5. Push para o repositório remoto
git push -u origin "$BRANCH_NAME"
echo "Pronto para abrir Pull Request atômico no GitHub!"

💡 Análise Passo a Passo do Código

  1. Rebase Diário com Trunk: Mantém a ramificação de trabalho sempre atualizada com as últimas alterações da equipe, prevenindo desvios profundos.
  2. Commits Convencionais: Uso de mensagens padronizadas (feat, fix, chore) para geração automatizada de changelogs e versionamento semântico.
  3. Submissão Rápida para Code Review: Branches com ciclo menor que 24 horas garantem validação imediata pelos pipelines de integração contínua.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Resolução de Conflitos Complexos e Rebasing Interativo 🔀

Objetivo Pedagógico

Objetivo: Dominar a estrutura de dados interna do Git (blobs, trees, commits, refs), o rebase interativo (git rebase -i), a resolução avançada de conflitos de merge e a ferramenta de segurança git reflog.

📑 1. Fundamentos Teóricos & Análise Técnica

O Git é fundamentalmente um sistema de arquivos indexado por conteúdo criptográfico (Content-Addressable Storage) baseado em um Grafo Acíclico Direcionado (DAG).

O domínio da manipulação do histórico do repositório exige conhecimento profundo das ferramentas de reestruturação: 1. Merge vs. Rebase: - git merge: Cria um Merge Commit com múltiplos pais, preservando o histórico histórico de bifurcação exato. Útil para registrar a integração formal de branches de release. - git rebase: Desconecta os commits da ramificação atual e os reaplica linearmente sobre a ponta da ramificação base. Resulta em um histórico limpo e sequencial (Linear History), facilitando auditorias e operações de git bisect. 2. Rebase Interativo (git rebase -i): Permite reescrever o histórico local antes de torná-lo público: - pick: Manter o commit. - reword: Alterar a mensagem do commit mantendo o código. - edit: Pausar para alterar arquivos no commit. - squash: Fundir o commit no commit anterior, combinando mensagens. - fixup: Fundir o commit no commit anterior, descartando a mensagem auxiliar. - drop: Descartar completamente o commit. 3. Resolução de Conflitos: Quando duas ramificações modificam os mesmos blocos de código, o Git interrompe a operação e insere marcadores de conflito (<<<<<<<, =======, >>>>>>>). A resolução técnica requer inspeção do ancestral comum (Base) via ferramentas como git merge-tool ou diff 3-way. 4. A Rede de Segurança Definitiva (git reflog): O Git mantém um diário de referência (Reference Log) gravando todas as movimentações do ponteiro HEAD. Qualquer commit acidentalmente perdido durante um rebase ou reset destrutivo pode ser recuperado a partir de seu hash no reflog.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    subgraph Histórico Antes do Rebase
        C1["Commit C1"] --> C2["Commit C2 (Base)"]
        C2 --> F1["Commit F1 (Feature)"]
        F1 --> F2["Commit F2 (Feature)"]
        C2 --> M1["Commit M1 (Main)"]
    end
    subgraph Histórico Após Rebase Linear
        M1 --> F1Prime["F1' (Reaplicado sobre M1)"]
        F1Prime --> F2Prime["F2' (Histórico 100% Linear)"]
    end
    style C1 fill:#e1f5fe,stroke:#01579b
    style M1 fill:#fff3e0,stroke:#e65100
    style F2Prime fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Regra de Ouro do Rebase: Jamais realize rebase em ramificações públicas compartilhadas por múltiplos desenvolvedores. - Diff 3-Way na Resolução: Análise comparando a versão Local (Ours), a versão Remota (Theirs) e o Ancestral Comum (Base). - Git Rerere (Reuse Recorded Resolution): Funcionalidade do Git que memoriza resoluções de conflitos passadas e as reaplica automaticamente em operações futuras. - Recuperação com Reflog: Capacidade de reverter qualquer estado anterior do repositório através de git reset --hard HEAD@{n}.

🛠️ 2. Implementação Prática em Git Internals, Rebase Interativo e Rastreabilidade

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// interactive_rebase_and_rescue.sh (Scripts de Rebase e Recuperação de Emergência)
#!/usr/bin/env bash
# 1. Iniciar rebase interativo dos últimos 3 commits para sanitizar histórico
# git rebase -i HEAD~3

# 2. Resolução de conflito durante rebase
# Supondo que um conflito ocorra em config.json:
echo "Resolvendo conflito manualmente..."
# (Edição do arquivo resolvendo marcadores <<<<<<< e >>>>>>>)
git add config.json

# Prosseguir com o rebase
git rebase --continue

# 3. Cenário de Emergência: Rebase desastroso ou commits perdidos!
# Como recuperar qualquer estado anterior usando reflog:
echo "Visualizando histórico absoluto do HEAD:"
git reflog -n 5

# Restaurar o repositório exatamente ao estado antes de iniciar o rebase
# git reset --hard HEAD@{1}
echo "Repositório restaurado com segurança absoluta!"

💡 Análise Passo a Passo do Código

  1. Uso de git rebase --continue: Permite avançar incrementalmente commit por commit na pilha de rebase após resolver conflitos pontuais.
  2. Inspeção de Reflog: Audita todos os saltos de ponteiro do repositório, garantindo que nenhum dado comitado seja destruído.
  3. Preservação da Linearidade: Produz grafos limpos que simplificam a identificação de bugs por bissecção binária.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Automação com Git Hooks e Assinatura de Commits 🛡️

Objetivo Pedagógico

Objetivo: Implementar barreiras automatizadas de qualidade usando Git Hooks (pre-commit, commit-msg, pre-push) com Husky e configurar a assinatura criptográfica de commits com chaves GPG/SSH para conformidade e autenticidade.

📑 1. Fundamentos Teóricos & Análise Técnica

A segurança do ciclo de vida de desenvolvimento de software (Software Supply Chain Security) começa no primeiro comando executado na máquina do desenvolvedor.

A combinação de automação de políticas e autenticação de identidade mitiga riscos graves: 1. Arquitetura de Git Hooks: - Os hooks do Git são scripts executáveis localizados no diretório .git/hooks/, acionados em pontos estratégicos do fluxo de trabalho: - pre-commit: Executa linters, verificadores de segredos (ex: detecção de tokens de API hardcoded) e testes rápidos antes do commit ser gravado. - commit-msg: Valida se a mensagem do commit obedece a especificações como o Conventional Commits (ex: type(scope): subject). - pre-push: Impede o envio de alterações caso a suíte de testes de integração falhe ou existam branches desatualizadas. - Ferramentas como Husky e pre-commit (Python) padronizam e versionam esses hooks no próprio repositório, garantindo que toda a equipe execute as mesmas validações.

  1. Assinatura Criptográfica de Commits (GPG / SSH):
  2. No Git puro, qualquer usuário pode configurar arbitrariamente git config user.name e git config user.email, impersonando outro membro da equipe com facilidade.
  3. A assinatura com chave assimétrica (GPG ou chaves SSH Ed25519) atesta matematicamente a autoria do commit. Plataformas como o GitHub verificam a chave pública cadastrada e exibem o badge Verified, garantindo rastreabilidade e não-repúdio em auditorias de conformidade (SOC 2, ISO 27001).

📐 Arquitetura Conceitual & Diagrama de Fluxo

sequenceDiagram
    autonumber
    participant Dev as Desenvolvedor
    participant Git as Git Engine Local (.git/hooks)
    participant GPG as Chave Criptográfica GPG/SSH
    participant Remote as GitHub / GitLab Remoto
    Dev->>Git: git commit -m "feat: login"
    Git->>Git: Executa pre-commit (Lint, Detect-Secrets)
    Git->>Git: Executa commit-msg (Valida Conventional Commits)
    Git->>GPG: Solicita assinatura do objeto commit
    GPG-->>Git: Assinatura Criptográfica Anexada
    Git-->>Dev: Commit Gravado com Assinatura!
    Dev->>Remote: git push origin main
    Remote->>Remote: Valida Chave Pública na PKI do GitHub
    Note over Remote: Badge "Verified" Concedido!

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Prevenção de Vazamento de Segredos: Bloqueio no hook pre-commit de senhas, certificados .pem e chaves privadas antes de atingirem o histórico de commits. - Padronização com Conventional Commits: Habilita geração automática de changelog e controle semântico de versão (SemVer) via commit-msg. - Assinatura Criptográfica com Ed25519: Criptografia assimétrica moderna e compacta que assegura integridade contra falsificação de commits. - Reprodutibilidade na Equipe: Sincronização de hooks versionados através de ferramentas como Husky ou frameworks de pre-commit.

🛠️ 2. Implementação Prática em Segurança de Cadeia de Suprimentos e Automação Git

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// git_security_setup.sh (Configuração de GPG Signing e Pre-commit Hook)
#!/usr/bin/env bash
# 1. Configurar assinatura de commit global com GPG ou SSH
# Exemplo com chave SSH Ed25519 moderna:
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

echo "Configuração de assinatura criptográfica ativada!"

# 2. Exemplo de script pre-commit hook para barrar credenciais
cat << 'EOF' > .git/hooks/pre-commit
#!/usr/bin/env bash
set -e

echo "[Pre-Commit] Verificando segredos acidentais..."
if git diff --cached | grep -E "(BEGIN RSA PRIVATE KEY|API_KEY=|SECRET_KEY=)"; then
    echo "ERRO: Possível segredo confidencial detectado no staged diff!"
    echo "Remova as credenciais antes de prosseguir com o commit."
    exit 1
fi

echo "[Pre-Commit] Validações de segurança concluídas com sucesso!"
EOF

chmod +x .git/hooks/pre-commit

💡 Análise Passo a Passo do Código

  1. Assinatura Automática (commit.gpgsign): Garante que todo commit seja assinado criptograficamente sem necessidade de passar flags manuais -S.
  2. Interceptação Pre-Commit: Verifica padrões de expressões regulares de chaves privadas e credenciais antes da persistência do commit.
  3. Execução Rápida em Staged Diff: Inspeciona apenas os arquivos que estão em estágio de inclusão (--cached), mantendo feedback em milissegundos.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀

Objetivo Pedagógico

Objetivo: Construir um ecossistema completo de colaboração em Git: pipelines de CI/CD autônomos no GitHub Actions, regras de proteção de branch (Branch Protection Rules), geração de releases semânticos automatizados e auditoria criptográfica.

📑 1. Fundamentos Teóricos & Análise Técnica

A culminação da disciplina de Versionamento e Colaboração é a engenharia de um ecossistema de entrega confiável, protegido contra erros humanos e alinhado aos padrões da indústria.

Este Projeto Capstone estabelece um pipeline de governança corporativa: 1. Proteção de Ramificações (Branch Protection & Rulesets): - A ramificação main torna-se imutável para pushes diretos (force-push estritamente desabilitado). - Exigência de aprovação mínima de revisores (Code Owners), com descarte de aprovações antigas ao ocorrerem novos commits. - Exigência mandatória de aprovação em verificações de status de CI (Required Status Checks) antes da liberação do botão de merge. 2. Pipelines de CI/CD Orientados a Eventos: - Disparo condicional de validações a cada Pull Request aberto contra a branch principal: checagem de linter, análise estática de segurança, execução de matriz de testes unitários e verificação de integridade de dependências. 3. Automação de Release Semântico (Semantic Release): - Análise automática dos commits da branch principal para deduzir a próxima versão semântica (MAJOR.MINOR.PATCH). - Geração dinâmica de tags Git assinadas, criação de Release no GitHub com notas de versão geradas a partir dos Pull Requests e publicação de artefatos de build.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    PR["Desenvolvedor abre Pull Request"] --> Checks["Required Status Checks (CI)"]
    Checks --> Lint["Linter & Format Check"]
    Checks --> Sec["Secret Scanner & SAST"]
    Checks --> Tests["Suíte de Testes Automatizados"]
    Checks --> Sign["Verificação de Assinatura GPG/SSH"]
    Lint & Sec & Tests & Sign --> Review["Code Review por CODEOWNERS"]
    Review --> Merge["Squash & Merge no Trunk (main)"]
    Merge --> ReleaseJob["Pipeline de Release Semântico"]
    ReleaseJob --> Tag["Tag Git Assinada (v2.0.0)"]
    ReleaseJob --> Changelog["Changelog & Release Notes Automáticos"]
    style PR fill:#e1f5fe,stroke:#01579b
    style Checks fill:#fff3e0,stroke:#e65100
    style Merge fill:#e8f5e9,stroke:#2e7d32
    style ReleaseJob fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - CODEOWNERS Declarativo: Arquivo que mapeia diretórios e tipos de arquivo a equipes especialistas para revisão compulsória. - Squash and Merge no Trunk: Compactação de commits secundários de trabalho em um commit único e expressivo no histórico principal. - Versionamento Semântico Automatizado: Eliminação de intervenção manual no cálculo de versões através da análise rigorosa de commits convencionais. - Imutabilidade de Histórico: Garantia de histórico linear auditável protegido contra exclusão acidental ou rebase destrutivo.

🛠️ 2. Implementação Prática em Automação DevOps, GitHub Actions e Governança de Código

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// ci_governance_capstone.yml (Pipeline GitHub Actions com Regras de Governança e Testes)
name: Governance & CI Pipeline

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  validate:
    name: Code Quality & Security Gate
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Código com Histórico Completo
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Configurar Node.js / Ferramental
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Validar Mensagens de Commit (Commitlint)
        if: github.event_name == 'pull_request'
        run: |
          npx @commitlint/cli --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose

      - name: Auditoria de Segredos e Vulnerabilidades
        run: |
          echo "Executando varredura de credenciais e dependências..."
          npm audit --audit-level=high

      - name: Executar Testes Automatizados
        run: |
          npm test -- --coverage

  release:
    name: Automated Semantic Release
    needs: validate
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          token: ${{ secrets.GITHUB_TOKEN }}
      - name: Semantic Release
        run: |
          echo "Calculando próxima versão semântica e gerando changelog autônomo..."

💡 Análise Passo a Passo do Código

  1. Fetch-Depth 0: Garante que o histórico completo esteja disponível para conferência do commitlint e cálculo de versão semântica.
  2. Commitlint em Pull Requests: Impede o merge de branches contendo mensagens que violem o padrão estabelecido da organização.
  3. Disparo Condicional de Release: Executa a geração de release apenas após a integração aprovada no branch main.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

Exercícios da Aula 01

🛠 Praticando os Conceitos Iniciais

Nível: Básico

  1. Verificando a Identidade do Git:

    • No seu terminal (ou Git Bash), digite o comando para verificar se o Git está instalado.
    • Se o comando retornar a versão, anote-a. Se não, prossiga para a próxima aula para aprender a instalar. 
      $ git --version

  2. Preparação de Perfil Profissional:

    • Acesse GitHub e crie sua conta (se não possuir).
    • Escolha um nome de usuário (username) curto e profissional. Evite apelidos informais em contextos de carreira.

Nível: Intermediário

  1. Simulação de Histórico Manual:

    • Crie uma pasta aula01-manual em seu computador.
    • Crie um arquivo documento.txt com a frase: "Texto original".
    • Agora, simule uma nova versão: faça uma cópia do arquivo chamada documento_v2.txt e mude o conteúdo para: "Texto alterado".
    • Pergunte-se: Como você saberia qual foi a data exata da mudança e quem a fez apenas olhando para os nomes dos arquivos?

  2. Exploração de Diferenças (Diff):

    • Compare visualmente os dois arquivos criados no exercício anterior. O que mudou? Como você descreveria essa mudança de forma técnica?

Nível: Desafio

  1. Pesquisa de Sistemas de Versionamento:
    • O Git é o sistema mais popular, mas não o único. Pesquise o nome de pelo menos dois outros sistemas de controle de versão (VCS) que existiam antes do Git ou que competem com ele hoje.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Verificando a Identidade do Git No seu terminal, o comando esperado é: 
git --version
**Resultado esperado**: Uma mensagem como `git version 2.x.x`. Se o comando não for reconhecido, a ferramenta ainda não está instalada ou não está no PATH do sistema. ### 2. Preparação de Perfil Profissional Resposta pessoal. O objetivo é garantir que você tenha acesso à plataforma GitHub. ### 3. Simulação de Histórico Manual **Resposta Reflexiva**: Sem um sistema como o Git, é impossível saber a data ou o autor apenas pelo nome do arquivo. Além disso, se você deletar o arquivo `v1` para poupar espaço, o histórico original será perdido para sempre. O Git resolve isso guardando apenas as diferenças ("deltas") entre as versões, sem duplicar arquivos desnecessariamente. ### 4. Exploração de Diferenças (Diff) A mudança foi a substituição da palavra "original" por "alterado". Em termos técnicos, removeríamos uma linha e adicionaríamos outra no mesmo lugar. ### 5. Pesquisa de Sistemas de Versionamento Alguns exemplos de outros sistemas de controle de versão (VCS): - **SVN (Subversion)**: Um dos antecessores mais famosos, baseado em modelo Centralizado. - **Mercurial (Hg)**: Um competidor distribuído contemporâneo do Git. - **Perforce (P4)**: Comum em grandes indústrias de games. - **CVS**: Um dos pioneiros do versionamento eletrônico.

Exercícios da Aula 02

🛠 Instalando e Configurando seu Ambiente

Nível: Básico

  1. Instalação do Git:

    • Baixe e instale o Git em seu sistema operacional a partir de git-scm.com.
    • No Windows, certifique-se de que a opção de usar o "Git Bash" esteja marcada durante o processo.

  2. Configurando sua Identidade:

    • Abra seu terminal (ou Git Bash) e configure seu nome e e-mail globais. 
      $ git config --global user.name "Seu Nome Completo"
$ git config --global user.email "seu.email@exemplo.com"

Nível: Intermediário

  1. Validação de Configurações:

    • Liste todas as configurações atuais do Git e localize as linhas user.name e user.email.
    • Qual comando você usou para visualizar essa lista?

  2. Configuração do Editor Padrão:

    • (Opcional) Configure o Visual Studio Code como seu editor padrão para o Git através do terminal. Pesquise o comando necessário.

Nível: Desafio

  1. Localizando o Arquivo de Configuração:
    • O Git armazena essas configurações globais em um arquivo físico no seu computador. Descubra o caminho exato e o nome desse arquivo em seu sistema operacional.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Instalação do Git Confirmação visual. Se o "Git Bash" abrir no seu Windows, a instalação foi um sucesso. ### 2. Configurando sua Identidade Os comandos são: 
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"
### 3. Validação de Configurações O comando utilizado para listar todas as configurações é: 
git config --list
**Alternativa**: Você também pode usar `git config user.name` para ver apenas o nome configurado. ### 4. Configuração do Editor Padrão Para configurar o VS Code como editor padrão do Git, o comando é: 
git config --global core.editor "code --wait"
### 5. Localizando o Arquivo de Configuração - **No Windows**: O arquivo `.gitconfig` geralmente está em `C:\Users\SEU-USUARIO\.gitconfig`. - **No Linux/macOS**: O arquivo está em `~/.gitconfig` (na raiz da sua pasta pessoal).

Exercícios da Aula 03

🛠 Repositórios, Commits e Histórico

Nível: Básico

  1. Iniciando a Jornada:

    • Crie uma pasta chamada meu-primeiro-git e entre nela pelo terminal.
    • Transforme essa pasta em um repositório Git. Qual o comando utilizado?

  2. O Primeiro Commit:

    • Crie um arquivo index.html com qualquer conteúdo.
    • Adicione o arquivo à Staging Area e realize o commit com a mensagem: "Adiciona index.html inicial".

Nível: Intermediário

  1. Rastreando o Estado:

    • Crie um arquivo estilos.css mas não o adicione ao Git ainda.
    • Digite um comando para verificar o estado atual do repositório. Em qual cor e seção o arquivo estilos.css aparece?

  2. Visualizando o Passado:

    • Realize o commit do arquivo estilos.css.
    • Visualize o histórico de commits do seu repositório. Como você faria para ver esse histórico de forma resumida (em uma única linha por commit)?

Nível: Desafio

  1. A Pasta Oculta:
    • Procure na sua pasta de projeto por uma pasta oculta chamada .git.
    • O que acontece se você deletar essa pasta e rodar o comando git status em seguida? (Dica: não faça isso em projetos reais!).

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Iniciando a Jornada O comando para transformar a pasta em um repositório é: 
git init
### 2. O Primeiro Commit A sequência de comandos é: 
git add index.html
git commit -m "Adiciona index.html inicial"
### 3. Rastreando o Estado O comando para verificar o estado é: 
git status
O arquivo `estilos.css` aparecerá em **Vermelho** na seção chamada **Untracked files** (Arquivos não rastreados). ### 4. Visualizando o Passado Para ver o histórico resumido em uma única linha por commit: 
git log --oneline
### 5. A Pasta Oculta Se você deletar a pasta `.git`, o Git deixará de reconhecer aquela pasta como um repositório. O comando `git status` retornará um erro: `fatal: not a git repository`. Você perderá todo o histórico de versões permanentemente.

Exercícios da Aula 04

🛠 Branches e Merges: Linhas do Tempo Parallel

Nível: Básico

  1. Explorando as Ramificações:

    • Liste todas as branches locais do seu repositório atual. Qual comando você utilizou?
    • Em qual branch você está trabalhando no momento?

  2. Criando uma Nova Realidade:

    • Crie uma branch chamada feature-teste.
    • Mude para essa nova branch. Qual comando você utilizou para a troca?

Nível: Intermediário

  1. Trabalho Isolado:

    • Dentro da branch feature-teste, crie um arquivo chamado segredo.txt e realize o commit.
    • Volte para a branch main. O arquivo segredo.txt ainda aparece na sua pasta? Por que?

  2. A Fusão (Merge):

    • Estando na branch main, realize a fusão (merge) da branch feature-teste.
    • Verifique se o arquivo segredo.txt agora aparece na sua branch principal.

Nível: Desafio

  1. Atalho Eficiente:
    • Existe um comando que permite criar uma nova branch e mudar para ela instantaneamente em um único passo. Descubra e execute esse comando para criar a branch ajuste-rapido.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Explorando as Ramificações O comando para listar as branches é: 
git branch
A branch atual estará marcada com um asterisco (`*`) e geralmente em uma cor diferente (verde no Git Bash). ### 2. Criando uma Nova Realidade Para criar: 
git branch feature-teste
Para trocar: 
git switch feature-teste
### 3. Trabalho Isolado Ao voltar para a `main`, o arquivo `segredo.txt` **não** aparece. Isso ocorre porque os arquivos no Git estão vinculados à branch atual. Como o commit do arquivo foi feito apenas na linha do tempo `feature-teste`, a branch `main` ainda não conhece essa alteração. ### 4. A Fusão (Merge) Para unir as branches: 
git merge feature-teste
Após o comando, o Git traz os commits da `feature-teste` para a `main`, e o arquivo `segredo.txt` passa a existir fisicamente na sua pasta enquanto você estiver na `main`. ### 5. Atalho Eficiente O comando "tudo em um" é: 
git switch -c ajuste-rapido
(O `-c` vem de *create*).

Exercícios da Aula 05

🛠 Resolução de Conflitos: O Poder da Escolha

Nível: Básico

  1. Provocando a Colisão:

    • Crie uma pasta treino-conflito e inicie o Git.
    • Crie um arquivo compras.txt com o texto: "Arroz, Feijão". Realize o commit inicial na main.
    • Crie uma branch extra e mude para ela. Altere o texto para: "Arroz, Feijão, Batata". Commite.
    • Volte para a main e altere o mesmo arquivo para: "Arroz, Feijão, Macarrão". Commite.
    • Tente fazer o merge da branch extra na main.

  2. Identificando os Sinais:

    • Após o comando de merge, o Git avisará sobre um conflito. Qual o comando você deve usar para ver quais arquivos estão com o estado de "both modified"?

Nível: Intermediário

  1. Limpando os Marcadores:

    • Abra o arquivo compras.txt. Localize os símbolos <<<<<<<, ======= e >>>>>>>.
    • Edite o arquivo para que ele contenha os três itens: "Arroz, Feijão, Batata, Macarrão".
    • Importante: Remova todos os marcadores de conflito do arquivo.

  2. Finalizando o Pacto:

    • Após salvar o arquivo resolvido, quais são os dois passos (comandos) finais para concluir o merge e registrar a solução no histórico?

Nível: Desafio

  1. Abortando a Operação:
    • Suponha que você começou um merge, deu conflito, e você percebeu que não era a hora certa de fazer isso. Descubra qual comando permite "cancelar" o merge em andamento e voltar ao estado anterior ao conflito.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Provocando a Colisão Confirmação visual. O merge deve falhar com a mensagem: `CONFLICT (content): Merge conflict in compras.txt`. ### 2. Identificando os Sinais O comando é: 
git status
Arquivos com conflito aparecerão como `both modified`. ### 3. Limpando os Marcadores Após editar o arquivo para conter "Arroz, Feijão, Batata, Macarrão" e remover as linhas com `<<<<`, `====` e `>>>>`, o arquivo deve ser salvo. ### 4. Finalizando o Pacto Os comandos finais são: 
git add compras.txt
git commit
*Observação*: No `git commit`, ele abrirá o editor para confirmar a mensagem de merge. Basta salvar e fechar. ### 5. Abortando a Operação Para cancelar um merge que deu conflito e voltar ao estado anterior: 
git merge --abort

Exercícios da Aula 06

🛠 Entrando na Rede: GitHub e Perfil Profissional

Nível: Básico

  1. Otimização de Perfil:

    • Acesse as configurações de perfil no seu GitHub.
    • Adicione uma foto de rosto clara (avatar) e preencha a "Bio" com suas principais tecnologias de interesse.
    • Adicione o link do seu LinkedIn no campo apropriado.

  2. Favoritando o Futuro:

    • Use a barra de busca e encontre um repositório famoso (ex: facebook/react).
    • Clique no botão Star para adicioná-lo aos seus favoritos. Onde você pode ver a lista de todos os repositórios que você deu "Star"?

Nível: Intermediário

  1. Explorando Comunidades:

    • Pesquise por um projeto Open Source que utilize a etiqueta (label) good first issue.
    • Encontre pelo menos uma "Issue" aberta que pareça amigável para iniciantes. Qual o título dessa issue?

  2. A Cópia Pessoal (Fork):

    • Realize um Fork de um repositório público qualquer para a sua própria conta.
    • O que mudou na URL do repositório após o Fork?

Nível: Desafio

  1. Entendendo o Heatmap:
    • Observe o seu gráfico de contribuições (o "paredão verde"). Descubra quais tipos de ações no GitHub (commits, PRs, Issues) fazem os quadradinhos ficarem verdes.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Otimização de Perfil Resposta prática. Verifique no seu próprio perfil se a foto e a bio estão visíveis. ### 2. Favoritando o Futuro Você pode ver todos os seus repositórios favoritados clicando na sua foto (canto superior direito) > **Your Stars**. ### 3. Explorando Comunidades Resposta pessoal baseada no projeto encontrado. A etiqueta `good first issue` é uma convenção para atrair novos colaboradores. ### 4. A Cópia Pessoal (Fork) A URL muda de `github.com/dono-original/projeto` para `github.com/seu-usuario/projeto`. Abaixo do nome do repositório, aparecerá uma mensagem indicando: "forked from dono-original/projeto". ### 5. Entendendo o Heatmap As ações que geram "verde" no gráfico de contribuições são: - Comitar na branch padrão (ex: `main`) ou em branches que foram mergeadas. - Abrir uma Issue. - Propor um Pull Request. - Responder a discussões em Pull Requests. *Observação*: Dar Stars ou dar Fork **não** gera quadradinhos verdes.

Exercícios da Aula 07

🛠 Sincronização: Repositórios Remotos e .gitignore

Nível: Básico

  1. A Prática do Clone:

    • Saia da pasta do seu projeto atual no terminal (cd ..).
    • Escolha um repositório público no GitHub (ex: um projeto de código aberto).
    • Utilize o comando de clonagem para baixar esse projeto completo para sua máquina. Qual o comando utilizado?

  2. Verificando o Vínculo:

    • Dentro da pasta do projeto que você acabou de clonar, digite um comando para listar os endereços remotos de fetch e push. O que o termo "origin" representa?

Nível: Intermediário

  1. Segurança com .gitignore:

    • No seu repositório de testes, crie um arquivo chamado configuracao_privada.txt.
    • Crie (ou edite) o arquivo .gitignore na raiz e adicione o nome do arquivo acima dentro dele.
    • Tente adicionar o arquivo ao Git (git add configuracao_privada.txt). O que acontece?

  2. Conexão Remota:

    • Imagine que você criou um repositório local e agora quer vinculá-lo a um novo repositório vazio no GitHub. Qual o comando utilizado para adicionar esse "vínculo remoto" com o apelido origin?

Nível: Desafio

  1. Ignorando por Padrão:
    • No seu arquivo .gitignore, adicione uma regra que ignore todos os arquivos que terminem com a extensão .log, independentemente do nome. Como você escreveu essa regra utilizando caracteres curinga?

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. A Prática do Clone O comando utilizado é: 
git clone URL_DO_REPOSITORIO
### 2. Verificando o Vínculo O comando é: 
git remote -v
O termo **"origin"** é o nome (apelido) padrão dado ao servidor remoto principal do seu projeto. ### 3. Segurança com .gitignore O Git ignorará o arquivo. Caso você tente forçar a adição via linha de comando, ele retornará uma mensagem avisando que o arquivo coincide com um padrão do seu `.gitignore`. ### 4. Conexão Remota O comando para vincular um repositório local a um remoto é: 
git remote add origin https://github.com/usuario/projeto.git
### 5. Ignorando por Padrão A regra com caractere curinga no `.gitignore` é: 
*.log
Isso fará com que o Git ignore arquivos como `erro.log`, `sistema.log` ou `debug.log`.

Exercícios da Aula 08

🛠 Colaboração: Pull Requests e Code Review

Nível: Básico

  1. Enviando para Revisão:

    • Crie uma branch chamada ajuste-readme no seu repositório local.
    • Faça uma pequena alteração no arquivo README.md, realize o commit e envie (push) para o GitHub.
    • No GitHub, visualize o botão amarelo sugerindo "Compare & pull request". Qual o primeiro passo para transformar esse push em um pedido oficial de inclusão?

  2. Identificando Mudanças:

    • Dentro de um Pull Request aberto, acesse a aba Files changed. O que as cores verde e vermelho representam nesta visualização?

Nível: Intermediário

  1. A Arte do Review:

    • Simule uma revisão em seu próprio código (Self-Review). Clique em uma linha de código alterada no PR e adicione um comentário perguntando: "Esta lógica pode ser simplificada?".
    • Como você faz para aprovar formalmente um PR (mesmo que seja o seu próprio para teste)?

  2. Integração Final:

    • Realize o Merge do seu Pull Request através do botão verde na interface do GitHub.
    • O que acontece com a branch ajuste-readme no histórico do GitHub após o merge ser concluído?

Nível: Desafio

  1. Rejeitando com Elegância:
    • Crie outro PR de teste. Imagine que a funcionalidade foi descartada. Localize o botão para fechar o Pull Request sem realizar o merge. O que acontece com os commits desse PR descartado?

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Enviando para Revisão O primeiro passo é clicar no botão **"Create pull request"**. Isso abrirá um formulário onde você deve preencher o título e a descrição das mudanças propostas. ### 2. Identificando Mudanças Na interface de Diff do GitHub: - **Vermelho**: Representa linhas removidas ou alteradas. - **Verde**: Representa linhas adicionadas ou o novo estado da linha alterada. ### 3. A Arte do Review Para aprovar um PR, deve-se clicar no botão **"Review changes"** (canto superior direito da aba de Diff), selecionar a opção **"Approve"** e enviar o comentário. ### 4. Integração Final Após o merge, os commits da branch `ajuste-readme` passam a fazer parte do histórico da branch `main`. A branch original no GitHub pode ser deletada com segurança através do botão "Delete branch" que aparece logo após o merge. ### 5. Rejeitando com Elegância Se você fechar um PR sem o merge, os commits continuam existindo na branch original, mas o código **não** é incorporado à `main`. O PR fica com o status cinza ("Closed") e pode ser reaberto no futuro se necessário.

Exercícios da Aula 09

🛠 Fluxo de Trabalho: GitHub Flow na Prática

Nível: Básico

  1. Sincronização Inicial:

    • Antes de iniciar qualquer tarefa, você deve garantir que sua branch local está atualizada com o servidor. Qual a sequência de dois comandos para garantir que você está na main e com o código mais recente?

  2. Criação Expressa:

    • Utilize o comando de atalho para criar uma branch chamada ajuste-texto e alternar para ela simultaneamente. Qual comando você utilizou?

Nível: Intermediário

  1. O Ciclo Completo:

    • Realize uma alteração simples em um arquivo, commite-a e envie-a para o GitHub.
    • No navegador, abra o Pull Request.
    • Após "aprovar" seu próprio PR, realize o merge. O que deve ser feito com a branch ajuste-texto no GitHub após o merge?

  2. Faxina de Branches:

    • Após o merge no servidor, sua branch local ainda existe. Como você deleta uma branch local que já foi integrada ao projeto?

Nível: Desafio

  1. Limpando Rastros Remotos:
    • Às vezes, deletamos branches no GitHub, mas o nosso Git local ainda "acha" que elas existem no servidor. Descubra e execute o comando git fetch com a opção --prune para limpar essas referências obsoletas.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Sincronização Inicial A sequência de comandos é: 
git switch main
git pull origin main
### 2. Criação Expressa O comando de atalho é: 
git switch -c ajuste-texto
### 3. O Ciclo Completo Após o merge bem-sucedido, a boa prática é **deletar a branch** no GitHub utilizando o botão "Delete branch" que aparece na página do Pull Request. ### 4. Faxina de Branches Para deletar a branch local: 
git branch -d ajuste-texto
*Dica*: Use `-D` (maiúsculo) se quiser forçar a deleção mesmo que o Git ache que o trabalho não foi totalmente integrado. ### 5. Limpando Rastros Remotos O comando para sincronizar a lista de branches remotas e remover as que já foram deletadas no servidor é: 
git fetch --prune
Ou, se quiser ser ainda mais específico: `git fetch origin --prune`.

Exercícios da Aula 10

🛠 Gestão e Organização: Issues e Projetos

Nível: Básico

  1. Registrando Tarefas:

    • Vá até a aba Issues do seu repositório de portfólio.
    • Crie uma nova Issue com o título: "Melhorar a descrição biográfica".
    • Adicione uma etiqueta (label) do tipo enhancement. Como você fez para adicionar essa etiqueta?

  2. Responsabilidade (Assignee):

    • Atribua a Issue criada no exercício anterior a você mesmo (Assignee). O que muda visualmente na lista de issues após essa ação?

Nível: Intermediário

  1. Visualização em Quadro (Kanban):

    • Acesse a aba Projects e crie um novo projeto do tipo "Board".
    • Adicione a Issue anterior ao quadro.
    • Mova o cartão da coluna "Todo" para a coluna "In Progress". Qual a vantagem de ver as tarefas nesse formato em vez de apenas uma lista?

  2. Marcos de Entrega (Milestones):

    • Crie um Milestone chamado "Lançamento da V1".
    • Associe sua Issue a este Milestone. Onde você consegue visualizar a barra de progresso do Milestone?

Nível: Desafio

  1. Automação com Palavras-Chave:
    • Crie uma nova branch para resolver a Issue "Melhorar a descrição biográfica".
    • Na descrição do seu Pull Request, utilize a palavra-chave Closes #X (onde X é o número da sua issue).
    • Após realizar o merge, verifique o que aconteceu com a Issue original. Ela ainda está aberta?

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Registrando Tarefas A etiqueta é adicionada no menu lateral direito da Issue, na seção **Labels**. Basta clicar na engrenagem e selecionar a opção desejada. ### 2. Responsabilidade (Assignee) Ao definir um Assignee, a foto (avatar) do usuário aparece na lista geral de Issues e também no cabeçalho da Issue específica, indicando quem é o responsável pela entrega. ### 3. Visualização em Quadro (Kanban) A grande vantagem do Kanban é a **visibilidade do fluxo**. É possível entender rapidamente quantos itens estão aguardando, quantos estão sendo feitos e identificar "gargalos" no processo. ### 4. Marcos de Entrega (Milestones) A barra de progresso pode ser vista na aba **Issues > Milestones**. Ela mostra a porcentagem de conclusão baseada na relação entre issues abertas e issues fechadas vinculadas àquele marco. ### 5. Automação com Palavras-Chave Ao utilizar `Closes #numero` ou `Fixes #numero`, o GitHub **fecha automaticamente** a Issue correspondente no momento exato em que o Pull Request é mergeado na branch padrão.

Exercícios da Aula 11

🛠 Boas Práticas: A Arte do Commit Profissional

Nível: Básico

  1. Gramática do Commit:

    • Escolha uma alteração recente no seu código. Escreva uma mensagem de commit curta e direta utilizando o Modo Imperativo. Qual foi o verbo utilizado?

  2. Trabalhando em Camadas:

    • Realize duas alterações diferentes em arquivos distintos do seu projeto.
    • Realize o commit de apenas um deles primeiro. Qual comando você utilizou para garantir que apenas um arquivo fosse para o "palco" (Staging Area)?

Nível: Intermediário

  1. Padrões de Indústria (Conventional Commits):

    • Utilize o prefixo feat: para registrar uma nova funcionalidade pequena e o prefixo docs: para registrar uma melhora no seu README.
    • Como as mensagens aparecem no seu git log após esses commits?

  2. O Corretor de Mensagens:

    • Realize um commit com uma mensagem genérica como "ajuste".
    • Sem fazer novas alterações nos arquivos, utilize o comando para emendar (amend) esse commit, trocando a mensagem para algo no padrão Conventional Commits (ex: refactor: organiza estrutura de pastas).

Nível: Desafio

  1. Entendendo a Atomicidade:
    • Pesquise e explique com suas palavras por que é considerado uma "má prática" commitar uma correção de bug de lógica e uma alteração de cor de botão no mesmo commit. Como isso afeta o processo de revert?

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Gramática do Commit Exemplos de verbos no imperativo: **Adiciona**, **Remove**, **Corrige**, **Atualiza**, **Refatora**. *Mensagem exemplo*: "Adiciona ícone de busca ao topo". ### 2. Trabalhando em Camadas Para adicionar apenas um arquivo específico: 
git add nome-do-arquivo.ext
Isso garante a atomicidade, enviando para o Stage apenas o que você deseja registrar naquele momento. ### 3. Padrões de Indústria As mensagens aparecem prefixadas, facilitando a leitura rápida: - `feat: ...` - `docs: ...` Ao usar `git log --oneline`, o histórico fica visualmente categorizado. ### 4. O Corretor de Mensagens O comando para alterar a mensagem do último commit é: 
git commit --amend -m "Sua nova mensagem aqui"
### 5. Entendendo a Atomicidade Commits atômicos (focados em uma única tarefa) são essenciais porque, se a nova funcionalidade causar um erro mas a correção de bug for necessária, você pode usar o comando `git revert` apenas no commit da funcionalidade. Se ambos estivessem no mesmo commit, você teria que reverter a correção do bug junto, ou desfazer as mudanças manualmente, o que gera risco e perda de tempo.

Exercícios da Aula 12

🛠 Documentação: Markdown e README Profissional

Nível: Básico

  1. Sintaxe de Títulos:

    • No seu editor de texto, crie um arquivo chamado rascunho.md.
    • Utilize a sintaxe de Markdown para criar títulos do nível 1 ao nível 3. Como os tamanhos mudam visualmente?

  2. Links e Ênfase:

    • No rascunho anterior, escreva uma frase contendo uma palavra em negrito e um link para o seu perfil do GitHub.

Nível: Intermediário

  1. Listas e Itens:

    • Crie uma lista com marcadores (bullet points) contendo 3 tecnologias que você aprendeu neste curso.
    • Em seguida, transforme essa lista em uma Checklist (com caixas de seleção [x]).

  2. Blocos de Código:

    • Adicione um bloco de código ao seu arquivo Markdown que contenha o comando para clonar um repositório. Use a "coloração de sintaxe" (syntax highlighting) para a linguagem Bash.
    • Como você indicou para o Markdown que aquele bloco era de código?

Nível: Desafio

  1. Tabelas e Organização:
    • Crie uma tabela com duas colunas: "Comando" e "Função".
    • Preencha com pelo menos 3 linhas (ex: git init, git commit, git push). Pesquise como alinhar o texto de uma coluna à direita.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Sintaxe de Títulos A sintaxe é: - `# Título 1` (Maior) - `## Título 2` - `### Título 3` (Menor) ### 2. Links e Ênfase Exemplo de frase formatada: "Este é o meu **perfil oficial** no [GitHub](https://github.com/seu-usuario)." ### 3. Listas e Itens Para a checklist: - [x] Git - [x] GitHub - [x] Markdown ### 4. Blocos de Código Para criar o bloco, usamos três crases (backticks) seguidas do nome da linguagem: 
git clone https://link-do-repo.git
O Markdown foi avisado através das três crases no início e no fim do bloco. ### 5. Tabelas e Organização Exemplo de tabela com alinhamento à direita na segunda coluna (`---:`): | Comando | Função | | :--- | ---: | | `git init` | Inicia repo | | `git commit` | Salva versão | | `git push` | Sobe código |

Exercícios da Aula 13

🛠 Trabalho em Equipe: Colaboração Profissional

Nível: Básico

  1. Convidando o Time:

    • Vá até as configurações (Settings) do seu repositório de portfólio.
    • Localize a aba "Collaborators" e adicione um colega ou uma conta secundária. Qual o e-mail ou usuário que você convidou?

  2. Verificando Permissões:

    • Pesquise no GitHub Docs qual a diferença prática entre as permissões de "Read" e "Write". O que um colaborador com acesso "Read" não consegue fazer em relação ao código-fonte?

Nível: Intermediário

  1. Sincronização Forçada (Pull):

    • Simule uma alteração feita por um colega: vá no GitHub e edite o seu README direto no navegador. Commite a mudança lá.
    • Agora, tente fazer uma alteração local no mesmo README e tente dar um push. Explique por que o Git rejeitou o seu envio e qual o comando você usou para resolver.

  2. Colaborador vs Contribuidor:

    • Se você encontrar um bug em um projeto famoso (como o VS Code), você conseguirá dar git push direto para o repositório deles? Por que?

Nível: Desafio

  1. Simulando o Fluxo de Time:
    • Crie uma Issue no repositório.
    • Atribua essa Issue ao seu colaborador.
    • O colaborador deve criar uma branch, resolver a Issue e abrir um PR.
    • Você deve revisar o código e realizar o Merge. Descreva brevemente como foi a experiência de ver o código de outra pessoa entrando no seu projeto.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Convidando o Time Resposta prática. O colaborador convidado deve aceitar o convite (via e-mail ou notificação no GitHub) para ter acesso de escrita ao projeto. ### 2. Verificando Permissões Um colaborador com acesso **Read** consegue ver o código, baixar o repositório e abrir issues, mas **não consegue dar push** diretamente para nenhuma branch. Ele precisaria fazer um Fork para contribuir. ### 3. Sincronização Forçada (Pull) O Git rejeita o envio porque o histórico local e remoto divergem (o remoto tem commits que o local não tem). É o erro de **non-fast-forward**. **Solução**: 
git pull origin main
Após baixar as mudanças e resolver possíveis conflitos, o `push` será aceito. ### 4. Colaborador vs Contribuidor Não, você não conseguirá dar `push` direto porque não é um **Colaborador** oficial (não tem permissão de escrita). Para contribuir, você deve agir como **Contribuidor**: fazer um Fork, alterar no seu repositório e enviar um Pull Request. ### 5. Simulando o Fluxo de Time Resposta reflexiva. A experiência de Pull Request e Merge é a base de como times de engenharia de software operam no mundo real, garantindo qualidade através do Code Review.

Exercícios da Aula 14

🛠 Hospedagem: GitHub Pages e Portfólio Online

Nível: Básico

  1. Ativação do Serviço:

    • Vá até as configurações (Settings) do seu projeto de portfólio.
    • Acesse a seção Pages e selecione para fazer o deploy a partir da branch main.
    • Salve as configurações. Qual é a URL gerada pelo GitHub para o seu site?

  2. Verificação do index.html:

    • Certifique-se de que o arquivo principal do seu site se chama exatamente index.html e está na raiz da pasta. O que aconteceria com a visualização do site se você renomeasse este arquivo para home.html?

Nível: Intermediário

  1. Deploy em Tempo Real:

    • Realize uma pequena alteração no texto do seu index.html localmente, faça o commit e o push.
    • Quanto tempo, em média, o GitHub levou para atualizar o site online após o seu envio?

  2. Monitorando a "Esteira" (Actions):

    • No GitHub, clique na aba Actions.
    • Você verá um "workflow" sendo executado automaticamente chamado pages-build-deployment. O que o ícone de cor verde indica nessa lista?

Nível: Desafio

  1. Temas Automáticos (Jekyll):
    • (Opcional) Em um repositório de teste que contenha apenas um README.md, tente usar o seletor de temas do GitHub Pages ("Choose a theme").
    • Como o GitHub transforma um simples arquivo de texto (.md) em um site formatado sem que você escreva uma única linha de HTML?

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Ativação do Serviço Resposta prática. A URL geralmente segue o padrão `https://seu-usuario.github.io/seu-repositorio/`. ### 2. Verificação do index.html Se o arquivo for renomeado para `home.html`, o GitHub Pages não conseguirá encontrar o ponto de entrada padrão. O usuário receberá um erro **404 (Not Found)** ou verá apenas a listagem de arquivos (caso o README não esteja configurado como fallback). ### 3. Deploy em Tempo Real Resposta prática. Geralmente o deploy leva entre **30 segundos a 2 minutos**, dependendo da fila de processamento do GitHub Actions. ### 4. Monitorando a "Esteira" (Actions) O ícone **verde** indica que o processo de "Build" (construção) e "Deployment" (publicação) foi concluído com sucesso e o site foi atualizado. ### 5. Temas Automáticos (Jekyll) O GitHub utiliza um motor chamado **Jekyll**. Ele lê o conteúdo do seu arquivo Markdown e o "injeta" dentro de um template HTML/CSS pronto. Isso permite focar apenas no conteúdo, deixando o design a cargo do gerador de site estático.

Exercícios da Aula 15

🛠 Troubleshooting: Resolvendo Problemas com Calma

Nível: Básico

  1. Recuperação Imediata:

    • Delete propositalmente o arquivo index.html da sua pasta de projeto (deletar fisicamente, não via git rm).
    • Use o comando git status para confirmar que o Git percebeu a ausência.
    • Qual comando você deve usar para restaurar o arquivo exatamente como ele estava no último commit?

  2. Corrigindo a Mensagem:

    • Realize um commit com a mensagem "errado".
    • Utilize o comando de emenda (amend) para trocar a mensagem para "feat: adiciona estrutura inicial".

Nível: Intermediário

  1. O Poder do Reset Suave:

    • Realize um commit qualquer.
    • Utilize o comando git reset --soft HEAD~1.
    • Após o comando, o que aconteceu com as suas alterações? Elas foram apagadas ou continuam na Staging Area (verde)?

  2. Saindo do Limbo (Detached HEAD):

    • Utilize o git log --oneline e copie o hash de um commit anterior.
    • Faça um checkout para esse hash. O Git avisará que você está em "detached HEAD".
    • Qual o comando mais simples para sair desse estado e voltar para a sua branch principal (main)?

Nível: Desafio

  1. A Gaveta de Emergência (Stash):
    • Imagine que você está no meio de uma alteração complexa, mas precisa mudar de branch para corrigir um bug urgente e não quer commitar o código incompleto.
    • Pesquise e utilize o comando git stash para "guardar" suas mudanças temporariamente. Como você faz para "recuperar" essas mudanças depois de voltar para a branch original?

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Recuperação Imediata O comando para restaurar o arquivo é: 
git restore index.html
### 2. Corrigindo a Mensagem O comando é: 
git commit --amend -m "feat: adiciona estrutura inicial"
### 3. O Poder do Reset Suave As alterações **continuam na Staging Area (verde)**. O `reset --soft` apenas "desfaz" o ato do commit, mas mantém todo o seu trabalho pronto para ser commitado novamente (útil para mudar a mensagem ou agrupar arquivos). ### 4. Saindo do Limbo (Detached HEAD) Para voltar ao estado normal, basta alternar novamente para uma branch nomeada: 
git switch main
### 5. A Gaveta de Emergência (Stash) - Para guardar: `git stash` - Para listar o que está guardado: `git stash list` - Para recuperar e remover da gaveta: `git stash pop` - Para recuperar mantendo uma cópia na gaveta: `git stash apply`

Exercícios da Aula 16

🛠 Próximos Passos: Carreira e Produtividade

Nível: Básico

  1. Destaques do Perfil (Pins):

    • No seu perfil do GitHub, utilize o recurso "Customize your pins" para fixar o seu repositório de portfólio no topo.
    • Por que é importante escolher manualmente quais repositórios aparecem no topo do seu perfil?

  2. Etiquetas Open Source:

    • Pesquise no GitHub Explore por issues com a label help wanted.
    • Encontre um projeto que você ache interessante e adicione-o aos seus "Stars".

Nível: Intermediário

  1. Atalhos de Produtividade (Aliases):

    • O Git permite criar apelidos (aliases) para comandos longos. Configure um alias global para que git s execute o comando status. 
      $ git config --global alias.s status
    • Teste o novo comando. Qual a vantagem de usar aliases no dia a dia?

  2. Faxina de Repositórios:

    • Identifique repositórios de "teste" ou "aprendizado" que você criou durante o curso e que não servem mais.
    • Utilize o recurso Archive do GitHub (em Settings) nesses repositórios. Qual a diferença entre arquivar e deletar um repositório?

Nível: Desafio

  1. A Jornada de Aprendizado:
    • Escreva um pequeno parágrafo no seu README.md principal relatando qual foi o conceito mais desafiador que você aprendeu neste curso e como você pretende usá-lo em seus projetos futuros.

---

📚 Gabarito e Solução Comentada

Gabarito Explicado ### 1. Destaques do Perfil (Pins) É importante porque permite que você direcione a atenção de recrutadores e outros desenvolvedores para os seus **melhores trabalhos**. Por padrão, o GitHub mostra os repositórios criados recentemente, que nem sempre são os mais representativos das suas habilidades. ### 2. Etiquetas Open Source Resposta prática. Encontrar projetos com `help wanted` ou `good first issue` é a porta de entrada para a comunidade mundial de desenvolvedores. ### 3. Atalhos de Produtividade (Aliases) O comando para configurar é: 
git config --global alias.s status
A vantagem é a **velocidade**. No dia a dia, economizar caracteres em comandos frequentes reduz a fadiga e aumenta a produtividade. ### 4. Faxina de Repositórios - **Deletar**: Remove o código e o histórico permanentemente. Não há volta. - **Arquivar**: O repositório torna-se "Somente Leitura". O código e o histórico continuam disponíveis e buscáveis, mas ninguém (nem você) pode fazer novos commits até que o repositório seja "desarquivado". ### 5. A Jornada de Aprendizado Resposta pessoal. Refletir sobre o aprendizado ajuda a fixar o conhecimento e demonstra maturidade profissional.

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01 - Criando as Bases do Portfólio

🚀 Objetivo

Neste curso, vamos desenvolver um Portfólio Profissional que servirá como sua vitrine técnica no mundo da tecnologia. O primeiro passo é apenas organizativo.

📋 Passo a Passo

1. Preparação da Pasta

  1. Escolha um local seguro no seu computador (ex: Documentos).
  2. Crie uma nova pasta chamada meu-portfolio-git.
  3. Nota: Evite usar espaços ou caracteres especiais em nomes de pastas de projetos.

2. O Primeiro Documento

  1. Abra a pasta meu-portfolio-git.
  2. Usando o VS Code (ou Bloco de Notas), crie um arquivo chamado sobre.txt.
  3. Dentro dele, escreva:
  4. Seu nome completo.
  5. Sua área de estudo (ex: "Estudante de Análise e Desenvolvimento de Sistemas").
  6. Salve o arquivo.

🔍 O que fizemos?

Por enquanto, esta é apenas uma pasta comum no seu computador. Nas próximas aulas, vamos transformá-la em um Repositório Git e começar a salvar suas versões!

Projeto 02 - Validando a Bancada de Trabalho

🚀 Objetivo

Garantir que as ferramentas de linha de comando estão prontas para atuar dentro da sua pasta de projeto.

📋 Passo a Passo

1. Acesso via Terminal

  1. Localize sua pasta meu-portfolio-git.
  2. Windows: Clique com o botão direito em um espaço vazio da pasta e escolha "Open Git Bash Here".
  3. Mac/Linux: Abra o terminal e navegue até a pasta usando o comando cd (ex: cd ~/Documentos/meu-portfolio-git).

2. Teste de Diagnóstico

No terminal aberto dentro da pasta, digite: 

git status

🔍 Resultado Esperado

Você deve ver uma mensagem de erro:

fatal: not a git repository (or any of the parent directories): .git

ISSO É UM SUCESSO! Significa que o Git está instalado corretamente e detectou que esta pasta ainda não começou a ser monitorada. Faremos isso na próxima aula!

Projeto 03 - O Primeiro Commit

🚀 Objetivo

Transformar sua pasta comum em um repositório oficial e realizar o primeiro salvamento histórico.

📋 Passo a Passo

1. Inicialização

Abra o Git Bash na pasta do seu portfólio e execute: 

git init
Observe que uma pasta oculta .git será criada.

2. Ciclo de Salvamento (Snapshot)

  1. Verifique o estado: 

    git status
    O arquivo sobre.txt aparecerá em vermelho (Untracked).

  2. Prepare para o commit: 

    git add sobre.txt

  3. Grave a versão: 

    git commit -m "feat: cria arquivo inicial sobre mim"

3. Auditoria do Histórico

Para confirmar que seu nome e a mensagem foram gravados, use: 

git log

🏆 Conquista

Seu projeto agora tem uma "âncora" no tempo. Você pode mudar o arquivo e, se errar, terá como voltar para este exato momento!

Projeto 04 - Isolamento com Branches

🚀 Objetivo

Aprender a trabalhar em funcionalidades novas sem colocar a versão principal em risco.

📋 Passo a Passo

1. Criando a Nova Linha do Tempo

No terminal do seu portfólio: 

git switch -c feat-contato
Este comando cria a branch e já muda você para ela.

2. Adicionando Funcionalidade

  1. Crie o arquivo contato.txt.
  2. Escreva seu e-mail ou LinkedIn.
  3. Salve, prepare e commite: 
    git add contato.txt
git commit -m "feat: adiciona informações de contato"

3. O Teste do Desaparecimento

  1. Volte para a branch principal: 
    git switch main
    (Ou master, dependendo da sua configuração).
  2. Olhe sua pasta: O arquivo contato.txt desapareceu! Ele existe apenas no "multiverso" da branch feat-contato.

4. A Fusão (Merge)

Agora, traga a novidade para a versão oficial: 

git merge feat-contato

🏆 Conquista

O arquivo reapareceu na branch principal. Você acaba de realizar um fluxo de trabalho profissional de isolamento.

Projeto 05 - Dominando Conflitos

🚀 Objetivo

Perder o medo de conflitos de merge através de uma simulação controlada e resolução manual.

📋 Passo a Passo

1. Criando a Divergência

  1. Crie uma branch chamada ajuste-texto: git switch -c ajuste-texto.
  2. Edite sobre.txt. Mude seu cargo para: "Desenvolvedor em Formação".
  3. Commite: git commit -am "style: altera cargo na branch" (o -a faz o add e commit juntos).

2. O Conflito na Branch Principal

  1. Volte para a main: git switch main.
  2. Edite o MESMO sobre.txt. Mude o cargo para: "Futuro Especialista em Git".
  3. Commite: git commit -am "style: altera cargo na main".

3. O Impacto

Tente unir as versões: 

git merge ajuste-texto
Você receberá o erro: CONFLICT (content): Merge conflict in sobre.txt.

4. A Resolução Manual

  1. Abra o arquivo no VS Code. Ele estará cheio de marcadores (<<<<, ====, >>>>).
  2. Apague o que não deseja e remova os marcadores. Deixe apenas o texto limpo.
  3. No terminal: 
    git add sobre.txt
git commit

🏆 Conquista

Você resolveu seu primeiro conflito! O Git agora tem um histórico unificado com a sua decisão final.

Projeto 06 - Sua Identidade Global

🚀 Objetivo

Configurar seu perfil no GitHub para que ele funcione como um currículo técnico atrativo para o mercado.

📋 Passo a Passo

1. Verificação de Perfil

  1. Acesse github.com/seu-usuario.
  2. Clique em Edit Profile.

2. Ajustes Profissionais

  • Nome: Use seu nome real e completo.
  • Bio: Escreva em uma frase o que você faz (ex: "Entusiasta de Open Source e Estudante de ADS").
  • Localização: Importante para recrutadores da sua região.
  • Link: Se tiver um LinkedIn, coloque aqui.

3. Auditoria de Segurança

  1. Vá em Settings > Password and authentication.
  2. Ative a Autenticação de Dois Fatores (2FA).
  3. Use um aplicativo como Google Authenticator ou Authy.
  4. Salve os códigos de recuperação em um local seguro (não no GitHub!).

🏆 Conquista

Seu perfil não é mais apenas uma página vazia; ele agora transmite profissionalismo e segurança.

Projeto 07 - Subindo para a Nuvem

🚀 Objetivo

Conectar seu repositório local ao GitHub e realizar seu primeiro envio (Push).

📋 Passo a Passo

1. Criando o "Balde" Remoto

  1. No GitHub, clique no + (canto superior) -> New repository.
  2. Nome: meu-portfolio-git.
  3. Escolha Public e NÃO marque as opções de Inicializar (README, .gitignore).
  4. Clique em Create repository.

2. A Ponte Digital

Copie a URL do repositório (ex: https://github.com/seu-usu/meu-portfolio-git.git) e, no terminal da sua pasta local, digite: 

git remote add origin SUA_URL_AQUI

3. O Lançamento

Envie seus commits para o servidor: 

git push -u origin main
(Se o terminal pedir login, siga as instruções para autenticar no navegador).

🏆 Conquista

Atualize a página do seu repositório no navegador. Mágica! Seu código agora está disponível em qualquer lugar do mundo.

Projeto 08 - O Fluxo Profissional (PR)

🚀 Objetivo

Praticar o ciclo completo de colaboração: Branch, Push, Pull Request e Merge no servidor.

📋 Passo a Passo

1. O Desenvolvedor em Ação

  1. Crie a branch: git switch -c feat-planos-futuros.
  2. Crie um arquivo planos.txt com uma lista de tecnologias que deseja aprender.
  3. Commite: git commit -am "feat: adiciona plano de estudos".
  4. Envie para o GitHub: git push -u origin feat-planos-futuros.

2. O Pedido de Inclusão

  1. No Site do GitHub, aparecerá um aviso amarelo: "Compare & pull request". Clique nele.
  2. Escreva uma descrição curta do que você está adicionando.
  3. Clique em Create pull request.

3. O Merge (Fusão)

  1. Finja que você revisou o próprio código (em empresas, um colega faria isso).
  2. Clique no botão verde Merge pull request.
  3. Confirme o Merge.

4. Sincronia Final

No seu terminal: 1. Volte para a main: git switch main. 2. Observe que o arquivo planos.txt não está lá! Baixe a atualização que você fez no site: 

git pull origin main

🏆 Conquista

Você acaba de completar o ciclo de vida de um software profissional. É exatamente assim que grandes empresas como Google e Microsoft trabalham.

Projeto 09 - Implementando o GitHub Flow

🚀 Objetivo

Simular um dia de trabalho real seguindo o fluxo ágil usado pelas maiores empresas de tecnologia.

📋 Passo a Passo

1. Sincronização Matinal

Antes de qualquer código, garanta que sua base está atualizada: 

git switch main
git pull origin main

2. Criação da Feature

Você recebeu a tarefa de adicionar suas Hard Skills (Tecnologias) no portfólio. 

git switch -c feat-tecnologias

3. Desenvolvimento Atômico

  1. Abra o arquivo sobre.txt.
  2. Adicione uma seção: ### 🛠 Tecnologias: HTML, CSS, Git, GitHub.
  3. Salve e grave localmente: 
    git add .
git commit -m "feat: adiciona lista de tecnologias principais"

4. Publicação e Revisão

  1. Envie a branch para o servidor: git push -u origin feat-tecnologias.
  2. No GitHub, abra o Pull Request.
  3. Realize o Merge após revisar os arquivos.

5. Limpeza de Terreno

Volte ao terminal e limpe a branch que já foi integrada: 

git switch main
git pull origin main
git branch -d feat-tecnologias

🏆 Conquista

Sua main está atualizada e seu repositório está limpo. Você completou o ciclo de vida standard do GitHub Flow.

Projeto 10 - Gestão com Issues e Projetos

🚀 Objetivo

Trabalhar como um desenvolvedor organizado, transformando ideias em tarefas rastreáveis e visuais.

📋 Passo a Passo

1. Mapeamento de Necessidades (Backlog)

No seu repositório no GitHub: 1. Vá em Issues e crie 3 novas tarefas: - docs: adicionar link do LinkedIn ao sobre.txt - feat: criar arquivo de projetos realizados - style: padronizar caixa alta nos títulos

2. Organização Visual (Kanban)

  1. Vá em Projects e crie um novo quadro (Board).
  2. Adicione as Issues criadas à coluna Todo.
  3. Arraste a primeira Issue para In Progress.

3. Automação de Fechamento

  1. No terminal, crie uma branch para resolver a primeira Issue.
  2. Ao realizar o Pull Request, escreva na descrição:

    "Este PR adiciona o link profissional e closes #1" (Substitua #1 pelo número da sua issue).

  3. Faça o Merge e verifique se a Issue foi fechada automaticamente.

🏆 Conquista

Você não apenas escreve código, você gerencia um projeto. Isso é o que diferencia amadores de profissionais.

Projeto 11 - A Arte do Commit Profissional

🚀 Objetivo

Aplicar o padrão Conventional Commits e entender a importância de mensagens claras para a manutenção do software.

📋 Passo a Passo

1. Identificando a Melhoria

Escolha uma pequena alteração estética no seu portfólio (ex: corrigir um erro de digitação ou mudar a ordem de uma lista).

2. Commit Semântico

Realize a alteração e, ao fazer o commit, use rigorosamente o prefixo correto: - Se for erro de digitação: fix: corrige typo no arquivo sobre.txt - Se for nova informação: feat: adiciona formação acadêmica - Se for apenas visual: style: melhora indentação do texto

3. Multi-Commits (Atomicidade)

Tente realizar duas melhorias separadas e faça dois commits distintos, um para cada ideia. 

git add arquivo1.txt
git commit -m "docs: atualiza bio"

git add arquivo2.txt
git commit -m "feat: adiciona link de rede social"

4. O Histórico Perfeito

Verifique o resultado com: 

git log --oneline

🏆 Conquista

Seu histórico agora é uma lista de tarefas compreensível por qualquer pessoa (ou robô!) no mundo.

Projeto 12 - O README "Gold Standard"

🚀 Objetivo

Transformar a documentação do seu projeto em uma vitrine de alto impacto visual e informativo.

📋 Passo a Passo

1. Estrutura Profissional

Crie ou edite o arquivo README.md na raiz do seu projeto com as seguintes seções: 1. # Título do Projeto 2. ## 📝 Descrição: Breve resumo do projeto. 3. ## 🛠 Tecnologias: Lista de ferramentas usadas. 4. ## 🚀 Como Executar: Comandos para clonar e usar. 5. ## 👤 Autor: Seu nome e links sociais.

2. Elementos Visuais (Markdown)

  • Badges: Use o site Shields.io para adicionar uma medalha de "Status: Concluído" ou "License: MIT".
  • Emojis: Use para deixar a leitura mais leve (🚀, 🛠, ✅).
  • Lista de Tarefas:
  • Inicializar Git
  • Subir para Nuvem
  • Configurar CI/CD

Se você tiver um print da tela do seu site ou portfólio, adicione-o com: ![Preview do Projeto](link-da-imagem.png)

🏆 Conquista

Seu repositório agora tem uma "cara" profissional. Compare com um projeto sem README e veja a diferença de autoridade.

Projeto 13 - Blindando o Repositório

🚀 Objetivo

Simular um ambiente corporativo de alta segurança, proibindo alterações diretas na versão de produção.

📋 Passo a Passo

1. Configuração de Bloqueio (Branch Protection)

No GitHub: 1. Vá em Settings > Branches. 2. Clique em Add branch protection rule. 3. Em "Branch name pattern", digite main. 4. Ative as opções: - Require a pull request before merging. - Require approvals (se possível). - Do not allow bypassing (aplica a regra até para você, o dono).

2. O Teste de Intrusão

  1. No seu computador, tente fazer uma alteração no README direto na main.
  2. Tente dar git push origin main.
  3. Resultado Esperado: O Git deve rejeitar seu push com uma mensagem de erro ("protected branch").

3. O Caminho Correto

  1. Crie uma branch: git switch -c fix-protecao.
  2. Realize a alteração, envie para o servidor e abra um Pull Request.

🏆 Conquista

Você acaba de implementar o padrão de segurança das Big Techs. Agora, nenhum código entra na main sem passar por uma revisão oficial.

Projeto 14 - O Portfólio no Ar

🚀 Objetivo

Transformar seu código em uma página web real e adicionar selos de monitoramento de status.

📋 Passo a Passo

1. Ativação do Site

  1. No GitHub, vá em Settings > Pages.
  2. Configure para subir a partir da branch main.
  3. Aguarde o link aparecer (ex: https://usuario.github.io/meu-portfolio-git/).

2. Melhoria Visual (HTML)

No seu arquivo index.html (se tiver um, ou crie um básico): 

<h1>Meu Portfólio Profissional</h1>
<p>Projetos desenvolvidos durante o curso de Git e GitHub.</p>
Salve, commite e dê push.

3. Badge de Deploy (Opcional)

Para mostrar que seu site está saudável, adicione este Markdown ao topo do seu README: 

![Status](https://github.com/SEU_USUARIO/meu-portfolio-git/actions/workflows/pages/pages-build-deployment/badge.svg)

🏆 Conquista

Abra o link do seu site no celular. Você acaba de publicar seu primeiro projeto na internet para o mundo inteiro ver!

Projeto 15 - Viajando no Tempo

🚀 Objetivo

Praticar técnicas de recuperação de arquivos e reversão de commits para nunca mais ter medo de errar.

📋 Passo a Passo

1. A Recuperação (Restore)

  1. Edite seu arquivo sobre.txt e apague metade do conteúdo (sem querer!).
  2. Salve o arquivo.
  3. No terminal, use: git restore sobre.txt.
  4. Verifique que o conteúdo voltou ao normal!

2. A Reversão (Reset Soft)

  1. Faça uma pequena alteração e dê um commit com uma mensagem errada (ex: git commit -m "asdjaslkd").
  2. Use o comando de rebobinar: 
    git reset --soft HEAD~1
  3. O commit "sumiu", mas o arquivo continua alterado e pronto para você commitar com a mensagem correta.

3. O Botão de Pânico (Reset Hard)

  1. Crie um arquivo teste_erro.txt e faça um commit.
  2. Agora, imagine que você quer deletar esse commit E o arquivo de uma só vez: 
    git reset --hard HEAD~1

🏆 Conquista

Você agora domina a "borracha" do Git. Erros não são mais permanentes, são apenas lições aprendidas.

Projeto 16 - O Legado e a Licença

🚀 Objetivo

Finalizar seu projeto com padrões de código aberto (Open Source) e preparar sua carreira para os próximos passos.

📋 Passo a Passo

1. Licenciamento

Diga ao mundo como eles podem usar seu código: 1. No GitHub, clique em Add file > Create new file. 2. Digite o nome: LICENSE. 3. Clique no botão Choose a license template. 4. Selecione a MIT License e clique em Review and submit.

2. Faxina Final

  1. Certifique-se de que não há branches abertas (faça merge de tudo).
  2. Delete branches locais que não servem mais: git branch -d nome-da-branch.
  3. Revise se seu README tem todos os links funcionando.

3. Fixando o Projeto (Pin)

  1. Vá na sua página inicial do perfil no GitHub.
  2. Clique em Customize your pins.
  3. Selecione o repositório deste curso para que ele apareça com destaque no seu topo.

🏆 Conquista Final

Seu repositório agora é um Projeto Gold Standard. De uma pasta vazia a um software versionado, documentado e licenciado. Parabéns pela jornada! 🎓🚀

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – O que é Controle de Versão e por que usar Git?

  1. Qual é o conceito fundamental e objetivo principal de O que é Controle de Versão e por que usar Git???
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de O que é Controle de Versão e por que usar Git???

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em O que é Controle de Versão e por que usar Git?, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em O que é Controle de Versão e por que usar Git???

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de O que é Controle de Versão e por que usar Git? atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em O que é Controle de Versão e por que usar Git?, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em O que é Controle de Versão e por que usar Git??

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a O que é Controle de Versão e por que usar Git? estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar O que é Controle de Versão e por que usar Git? com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a O que é Controle de Versão e por que usar Git? deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Instalando e Configurando o Git

  1. Qual é o conceito fundamental e objetivo principal de Instalando e Configurando o Git?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Instalando e Configurando o Git?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Instalando e Configurando o Git, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Instalando e Configurando o Git?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Instalando e Configurando o Git atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Instalando e Configurando o Git, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Instalando e Configurando o Git?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Instalando e Configurando o Git estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Instalando e Configurando o Git com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Instalando e Configurando o Git deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Repositórios, Commits e Histórico

  1. Qual é o conceito fundamental e objetivo principal de Repositórios, Commits e Histórico?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Repositórios, Commits e Histórico?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Repositórios, Commits e Histórico, Commits e Histórico, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Repositórios, Commits e Histórico?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Repositórios, Commits e Histórico atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Repositórios, Commits e Histórico, Commits e Histórico, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Repositórios, Commits e Histórico?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Repositórios, Commits e Histórico estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Repositórios, Commits e Histórico com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Repositórios, Commits e Histórico deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Branches e Merges: As Linhas do Tempo

  1. Qual é o conceito fundamental e objetivo principal de Branches e Merges: As Linhas do Tempo?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Branches e Merges: As Linhas do Tempo?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Branches e Merges: As Linhas do Tempo, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Branches e Merges: As Linhas do Tempo?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Branches e Merges: As Linhas do Tempo atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Branches e Merges: As Linhas do Tempo, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Branches e Merges: As Linhas do Tempo?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Branches e Merges: As Linhas do Tempo estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Branches e Merges: As Linhas do Tempo com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Branches e Merges: As Linhas do Tempo deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Resolução de Conflitos: O Dilema da Escolha

  1. Qual é o conceito fundamental e objetivo principal de Resolução de Conflitos: O Dilema da Escolha?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Resolução de Conflitos: O Dilema da Escolha?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Resolução de Conflitos: O Dilema da Escolha, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Resolução de Conflitos: O Dilema da Escolha?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Resolução de Conflitos: O Dilema da Escolha atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Resolução de Conflitos: O Dilema da Escolha, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Resolução de Conflitos: O Dilema da Escolha?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Resolução de Conflitos: O Dilema da Escolha estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Resolução de Conflitos: O Dilema da Escolha com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Resolução de Conflitos: O Dilema da Escolha deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Introdução ao GitHub: Sua Casa na Nuvem

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao GitHub: Sua Casa na Nuvem?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao GitHub: Sua Casa na Nuvem?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao GitHub: Sua Casa na Nuvem, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao GitHub: Sua Casa na Nuvem?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao GitHub: Sua Casa na Nuvem atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao GitHub: Sua Casa na Nuvem, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao GitHub: Sua Casa na Nuvem?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao GitHub: Sua Casa na Nuvem estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao GitHub: Sua Casa na Nuvem com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao GitHub: Sua Casa na Nuvem deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Repositórios Remotos: Conectando-se ao Mundo

  1. Qual é o conceito fundamental e objetivo principal de Repositórios Remotos: Conectando-se ao Mundo?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Repositórios Remotos: Conectando-se ao Mundo?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Repositórios Remotos: Conectando-se ao Mundo, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Repositórios Remotos: Conectando-se ao Mundo?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Repositórios Remotos: Conectando-se ao Mundo atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Repositórios Remotos: Conectando-se ao Mundo, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Repositórios Remotos: Conectando-se ao Mundo?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Repositórios Remotos: Conectando-se ao Mundo estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Repositórios Remotos: Conectando-se ao Mundo com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Repositórios Remotos: Conectando-se ao Mundo deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Pull Requests e Code Review: O Coração da Colaboração

  1. Qual é o conceito fundamental e objetivo principal de Pull Requests e Code Review: O Coração da Colaboração?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Pull Requests e Code Review: O Coração da Colaboração?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Pull Requests e Code Review: O Coração da Colaboração, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Pull Requests e Code Review: O Coração da Colaboração?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Pull Requests e Code Review: O Coração da Colaboração atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Pull Requests e Code Review: O Coração da Colaboração, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Pull Requests e Code Review: O Coração da Colaboração?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Pull Requests e Code Review: O Coração da Colaboração estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Pull Requests e Code Review: O Coração da Colaboração com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Pull Requests e Code Review: O Coração da Colaboração deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Fluxo de Trabalho: GitHub Flow

  1. Qual é o conceito fundamental e objetivo principal de Fluxo de Trabalho: GitHub Flow?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Fluxo de Trabalho: GitHub Flow?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Fluxo de Trabalho: GitHub Flow, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Fluxo de Trabalho: GitHub Flow?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Fluxo de Trabalho: GitHub Flow atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Fluxo de Trabalho: GitHub Flow, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Fluxo de Trabalho: GitHub Flow?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Fluxo de Trabalho: GitHub Flow estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Fluxo de Trabalho: GitHub Flow com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Fluxo de Trabalho: GitHub Flow deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Issues e Projetos: Organizando o Caos

  1. Qual é o conceito fundamental e objetivo principal de Issues e Projetos: Organizando o Caos?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Issues e Projetos: Organizando o Caos?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Issues e Projetos: Organizando o Caos, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Issues e Projetos: Organizando o Caos?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Issues e Projetos: Organizando o Caos atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Issues e Projetos: Organizando o Caos, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Issues e Projetos: Organizando o Caos?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Issues e Projetos: Organizando o Caos estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Issues e Projetos: Organizando o Caos com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Issues e Projetos: Organizando o Caos deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Boas Práticas: A Arte do Commit

  1. Qual é o conceito fundamental e objetivo principal de Boas Práticas: A Arte do Commit?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Boas Práticas: A Arte do Commit?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Boas Práticas: A Arte do Commit, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Boas Práticas: A Arte do Commit?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Boas Práticas: A Arte do Commit atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Boas Práticas: A Arte do Commit, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Boas Práticas: A Arte do Commit?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Boas Práticas: A Arte do Commit estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Boas Práticas: A Arte do Commit com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Boas Práticas: A Arte do Commit deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Documentação: README Profissional e Markdown

  1. Qual é o conceito fundamental e objetivo principal de Documentação: README Profissional e Markdown?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Documentação: README Profissional e Markdown?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Documentação: README Profissional e Markdown, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Documentação: README Profissional e Markdown?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Documentação: README Profissional e Markdown atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Documentação: README Profissional e Markdown, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Documentação: README Profissional e Markdown?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Documentação: README Profissional e Markdown estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Documentação: README Profissional e Markdown com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Documentação: README Profissional e Markdown deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Trabalho em Equipe: Colaboração Profissional

  1. Qual é o conceito fundamental e objetivo principal de Trabalho em Equipe: Colaboração Profissional?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Trabalho em Equipe: Colaboração Profissional?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Trabalho em Equipe: Colaboração Profissional, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Trabalho em Equipe: Colaboração Profissional?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Trabalho em Equipe: Colaboração Profissional atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Trabalho em Equipe: Colaboração Profissional, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Trabalho em Equipe: Colaboração Profissional?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Trabalho em Equipe: Colaboração Profissional estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Trabalho em Equipe: Colaboração Profissional com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Trabalho em Equipe: Colaboração Profissional deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – GitHub Pages: Seu Portfólio Online

  1. Qual é o conceito fundamental e objetivo principal de GitHub Pages: Seu Portfólio Online?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de GitHub Pages: Seu Portfólio Online?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em GitHub Pages: Seu Portfólio Online, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em GitHub Pages: Seu Portfólio Online?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de GitHub Pages: Seu Portfólio Online atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em GitHub Pages: Seu Portfólio Online, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em GitHub Pages: Seu Portfólio Online?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a GitHub Pages: Seu Portfólio Online estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar GitHub Pages: Seu Portfólio Online com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a GitHub Pages: Seu Portfólio Online deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Troubleshooting: Erros Comuns e Soluções

  1. Qual é o conceito fundamental e objetivo principal de Troubleshooting: Erros Comuns e Soluções?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Troubleshooting: Erros Comuns e Soluções?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Troubleshooting: Erros Comuns e Soluções, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Troubleshooting: Erros Comuns e Soluções?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Troubleshooting: Erros Comuns e Soluções atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Troubleshooting: Erros Comuns e Soluções, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Troubleshooting: Erros Comuns e Soluções?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Troubleshooting: Erros Comuns e Soluções estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Troubleshooting: Erros Comuns e Soluções com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Troubleshooting: Erros Comuns e Soluções deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Carreira, Portfólio e Próximos Passos

  1. Qual é o conceito fundamental e objetivo principal de Carreira, Portfólio e Próximos Passos?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Carreira, Portfólio e Próximos Passos?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Carreira, Portfólio e Próximos Passos, Portfólio e Próximos Passos, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Carreira, Portfólio e Próximos Passos?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Carreira, Portfólio e Próximos Passos atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Carreira, Portfólio e Próximos Passos, Portfólio e Próximos Passos, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Carreira, Portfólio e Próximos Passos?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Carreira, Portfólio e Próximos Passos estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Carreira, Portfólio e Próximos Passos com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Carreira, Portfólio e Próximos Passos deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀

  1. Qual o propósito principal de Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Estratégias Avançadas de Ramificação (Git Flow e Trunk-Based) 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Resolução de Conflitos Complexos e Rebasing Interativo 🚀

  1. Qual o propósito principal de Resolução de Conflitos Complexos e Rebasing Interativo 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Resolução de Conflitos Complexos e Rebasing Interativo 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Resolução de Conflitos Complexos e Rebasing Interativo 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Resolução de Conflitos Complexos e Rebasing Interativo 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Resolução de Conflitos Complexos e Rebasing Interativo 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Resolução de Conflitos Complexos e Rebasing Interativo 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Resolução de Conflitos Complexos e Rebasing Interativo 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Resolução de Conflitos Complexos e Rebasing Interativo 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Resolução de Conflitos Complexos e Rebasing Interativo 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Resolução de Conflitos Complexos e Rebasing Interativo 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Automação com Git Hooks e Assinatura de Commits 🚀

  1. Qual o propósito principal de Automação com Git Hooks e Assinatura de Commits 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Automação com Git Hooks e Assinatura de Commits 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Automação com Git Hooks e Assinatura de Commits 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Automação com Git Hooks e Assinatura de Commits 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Automação com Git Hooks e Assinatura de Commits 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Automação com Git Hooks e Assinatura de Commits 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Automação com Git Hooks e Assinatura de Commits 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Automação com Git Hooks e Assinatura de Commits 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Automação com Git Hooks e Assinatura de Commits 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Automação com Git Hooks e Assinatura de Commits 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀

  1. Qual o propósito principal de Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Fluxo Autônomo de Integração e Colaboração 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Ambientes de Desenvolvimento e Configuração 🛠️

Guias oficiais passo a passo para configurar suas ferramentas profissionais de desenvolvimento para Git e GitHub.

Setup 01: Instalação e Configuração Global do Git 🛠️

Objetivo da Configuração

Objetivo: Instalação do Git no Windows/Linux e parametrização de user.name, user.email, init.defaultBranch e core.editor.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Git e GitHub.

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Git e GitHub..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Setup 02: GitHub CLI (gh) e Autenticação 🛠️

Objetivo da Configuração

Objetivo: Instalação da CLI oficial do GitHub para gerenciar repositórios, PRs e issues direto do terminal.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Git e GitHub.

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Git e GitHub..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Setup 03: Chaves Criptográficas SSH (ED25519) 🛠️

Objetivo da Configuração

Objetivo: Geração e configuração de chaves SSH para autenticação segura no GitHub sem senhas.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Git e GitHub.

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Git e GitHub..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Setup 04: Extensões GitLens e GitGraph no VS Code 🛠️

Objetivo da Configuração

Objetivo: Visualização de histórico de commits, branches e autoria linha a linha no VS Code.

1. Pré-Requisitos e Visão Geral

A configuração correta deste ambiente é fundamental para o desenvolvimento eficiente e sem atritos ao longo do curso de Git e GitHub.

2. Passo a Passo de Instalação e Configuração

📥 Passo 1: Download e Instalação

Siga as instruções oficiais correspondentes ao seu sistema operacional (Windows, Linux ou macOS): - Baixe o pacote oficial da ferramenta diretamente do site do mantenedor. - Execute o assistente de instalação habilitando a opção de adicionar os binários à variável de ambiente PATH.

⚙️ Passo 2: Verificação no Terminal

Abra uma nova janela de terminal e valide se o comando está acessível: 

# Verificação de versão instalada
echo "Validando ambiente de Git e GitHub..."

💻 Passo 3: Configuração no Editor / IDE

  • Instale as extensões recomendadas para obter destaque de sintaxe, autocompletar e linters integrados.
  • Reinicie o editor para carregar os novos caminhos de execução.

3. Teste Rápido de Validação

Crie um arquivo de teste simples para comprovar que o compilador, interpretador ou ferramenta está operando com 100% de sucesso.

🎯 Próximos Passos

Com o ambiente configurado, você está pronto para iniciar as aulas práticas e desenvolver os projetos da disciplina.

Sobre

Sobre o Curso

🎓 Git e GitHub

Este é um curso completo e estruturado de Versionamento de Código com Git e GitHub. Desenvolvido para levar você do básico ao avançado, com uma abordagem prática e focada nas necessidades reais do mercado de desenvolvimento de software e colaboração em times ágeis.

🎯 Objetivos do Curso

  • Dominar Git

    Aprender os comandos fundamentais (Add, Commit, Branch, Merge) e como o Git funciona por baixo dos panos.

  • GitHub Profissional

    Utilizar o GitHub não apenas como repositório, mas como plataforma de colaboração, gestão de projetos e portfólio.

  • Colaboração

    Trabalhar em equipe utilizando Pull Requests, Code Reviews e resolvendo conflitos de forma eficiente.

  • Boas Práticas

    Criar um histórico de commits limpo, seguir padrões como Conventional Commits e manter repositórios organizados.

📚 O Que Você Vai Aprender

Módulo 1 – Conceitos Básicos

  • O que é controle de versão (Centralizado vs Distribuído)
  • Instalação e configuração inicial (Identidade)
  • Ciclo de vida dos arquivos e comandos base
  • Ramificação (Branching) e Fusão (Merging)

Módulo 2 – Trabalhando com GitHub

  • Repositórios Remotos e Sincronização (Push/Pull/Clone)
  • Resolução de Conflitos e Mediação de Código
  • Introdução à Interface Social do GitHub
  • Primeiros passos em Repositórios Remotos

Módulo 3 – Fluxos e Organização

  • GitHub Flow: O fluxo de trabalho moderno
  • Pull Requests e a Cultura de Code Review
  • Boas práticas de Mensagens de Commit
  • Documentação com Markdown e README Profissional

Módulo 4 – Colaboração e Carreira

  • Gestão de Projetos com Issues e Kanban Boards
  • Publicação de sites estáticos com GitHub Pages
  • Tratamento de erros comuns (Detached HEAD, Reset, Reflog)
  • Contribuição Open Source e Construção de Portfólio

🛠️ Metodologia

  • Aulas em Markdown

    Conteúdo técnico escrito de forma clara, focado na prática e no terminal.

  • Exercícios Reais

    Mão na massa com desafios que simulam o dia a dia de um desenvolvedor.

  • Projetos para Portfólio

    Construa um repositório real que servirá como vitrine para recrutadores.

  • Quizzes Interativos

    Teste seus conhecimentos ao final de cada módulo com feedback instantâneo.

👨‍🎓 Para Quem é Este Curso

  • Iniciantes que nunca usaram controle de versão e querem começar certo.
  • Desenvolvedores que usam Git apenas no básico ("add, commit, push") e querem profissionalizar o fluxo.
  • Estudantes que precisam organizar seus trabalhos e colaborar em projetos acadêmicos.
  • Profissionais que buscam se destacar com um perfil de GitHub organizado e atraente.

📋 Pré-requisitos

  • Computador com Windows, Linux ou macOS.
  • Instalação do Git (ensinada no curso).
  • Conta gratuita no GitHub.
  • Não é necessário saber programar para este curso!

🎖️ O Que Você Receberá

  • ✅ 16 aulas completas, teóricas e práticas.
  • ✅ Slides interativos em Reveal.js.
  • ✅ Quizzes interativos integrados.
  • ✅ 16 listas de exercícios progressivos.
  • ✅ Projetos práticos para seu Portfólio.
  • ✅ Guia de configuração de ambiente passo a passo.

🚀 Comece Agora

Pronto para dominar o controle de versão e elevar sua carreira?

Ir para Aula 01 Configurar Ambiente

Dúvidas? Entre em contato ou acesse os materiais complementares.

Roadmap do Projeto: Curso de Git e GitHub

Este documento rastreia o progresso do desenvolvimento do curso de Git e GitHub para Iniciantes.

✅ Fase 1: Estruturação e Conteúdo Base (Concluído)

  • Definição da ementa (16 aulas)
  • Criação da estrutura de diretórios (docs/aulas, docs/slides, etc.)
  • Geração de conteúdo inicial para todas as 16 aulas
  • Geração de slides para todas as 16 aulas (Reveal.js)
  • Criação de quizzes e exercícios básicos

🚧 Fase 2: Revisão e Polimento (Em Andamento)

  • Revisão Técnica: Verificar precisão dos comandos Git.
  • Revisão Pedagógica: Melhorar clareza e fluxo das explicações.
  • Design e UX:
    • Ajustar tema para cores do GitHub (Dark Mode).
    • Melhorar layout dos slides.
    • Padronizar imagens e diagramas (Mermaid).
  • Interatividade:
    • Adicionar quizzes interativos.
    • Criar projetos práticos.

🚀 Fase 3: Automação e Deploy (Concluído)

  • Configuração do MkDocs (mkdocs.yml).
  • Configuração de automação de testes.
  • Testes automatizados de build e links quebrados.

📦 Fase 4: Lançamento

  • Deploy final no GitHub Pages (branch gh-pages).
  • Divulgação inicial.

Status Atual: Fase 4 - Lançamento e Manutenção. Última Atualização: 16/02/2026

Materiais

Bem-vindo à seção de materiais complementares do curso. Aqui você encontra recursos adicionais para apoiar seus estudos.

  • Slides --- Acesse os slides de todas as aulas para revisão.

  • Exercícios --- Pratique com listas de exercícios para cada módulo.

  • Quizzes --- Teste seus conhecimentos com quizzes interativos.

  • Projetos --- Desenvolva projetos práticos para aplicar o que aprendeu.

  • Setups --- Guias de instalação e configuração do ambiente.

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.