Pular para o conteúdo principal

Lab 00 — Git, GitHub e gh

🗺️ Mapa de tarefas — 17 tarefas · 100 pts (clique para expandir)
  • T1 — Salvar evidencias/git-config.txt com user.name e user.email configurados (5 pts)
  • T2 — Criar README.md com um cabecalho H1 e um paragrafo de introducao (5 pts)
  • T3 — Adicionar cabecalhos H2/H3, negrito, italico e codigo inline ao README.md (6 pts)
  • T4 — Adicionar lista nao-ordenada com sublista, lista ordenada e lista de tarefas ao README.md (6 pts)
  • T5 — Adicionar ao menos dois links e uma imagem (badge) ao README.md (5 pts)
  • T6 — Adicionar um bloco de codigo com identificacao de linguagem (ex. bash) ao README.md (5 pts)
  • T7 — Adicionar uma tabela Markdown com cabecalho e ao menos duas linhas ao README.md (5 pts)
  • T8 — Adicionar uma citacao e uma regra horizontal ao README.md (5 pts)
  • T9 — Adicionar um .gitignore que ignora arquivos temporarios e de sistema (5 pts)
  • T10 — Criar branch, fazer merge na main e salvar evidencias/git-branch.txt (8 pts)
  • T11 — Salvar evidencias/gh-auth.txt (login) e evidencias/gh-repo.txt (owner/nome/branch) (5 pts)
  • T12 — Montar o README.md final com sumario de ancoras e todas as secoes integradas (12 pts)
  • T13 — Publicar o release v1.0.0 com gh release create (8 pts)
  • T14 — Abrir um pull request com gh e salvar a URL em evidencias/gh-pr.txt (5 pts)
  • T15 — Abrir uma issue com gh e salvar a URL em evidencias/gh-issue.txt (5 pts)
  • T16 — Provocar e resolver um conflito de merge, mantendo as duas versoes em conflito.txt (5 pts)
  • T17 — Usar gh api para confirmar a tag do release e salvar evidencias/gh-api.txt (5 pts)

Total: 100 pts

Antes de começar

Confira o ambiente (faça a configuração uma vez por máquina; a verificação, a cada aula):

  1. Instalar as ferramentas — git, GitHub CLI e VS Code
  2. Configurar o git — nome, e-mail e editor padrão (uma vez)
  3. Verificar git, gh e VS Code — deve mostrar as versões e Logged in to github.com

Verificação rápida de versão instalada:

git -v && gh --version && code -v && pio --version && wokwi-cli -V && wsl --version && docker --version

Verificação rápida de autenticação:

git config --get-regexp ^user\. && gh auth status && code --list-extensions --profile "ESP32IO"

Ao terminar — máquina de laboratório

Antes de sair, faça logout para não deixar sua conta do GitHub ativa na máquina (limpa a credencial salva do git e encerra a sessão do gh).


Toda entrega do curso é feita por commit: cada tarefa avaliada vira um commit cuja mensagem começa com Tn:, e o autograder corrige exatamente o estado daquele commit. Antes de tudo, você precisa dominar a ferramenta de entrega. Neste Lab 00 você aprende git (versionamento local), GitHub (o remoto da organização), gh (o GitHub CLI) e Markdown — a linguagem em que se escreve todo README.md, issue e pull request do curso.

Clone o repositório inicial do LAB00​

Escolha o Grupo e entre com o comando abaixo para criar o repositório no GitHub:

1. Crie e entre na pasta-mãe da disciplina:

mkdir "%USERPROFILE%\ELT85BN21" & cd /d "%USERPROFILE%\ELT85BN21"

2. Clone e entre no repositório do laboratório:

git clone https://github.com/ELT85B-N21-2026-2/lab00-grupo-a.git && cd lab00-grupo-a

3. Verifique status e abra o conteúdo do repositório no perfil ESP32IO do VS Code :

git status && code . --profile "ESP32IO"

Repositório do Grupo A para Laboratório 00:

  1. Copie o link do repositório acima.
  2. Abra a página de envio da atividade no Moodle (botão abaixo).
  3. Clique em Adicionar envio.
  4. Cole o link no campo Texto online.
  5. Clique em Salvar mudanças.
  6. Confira se o status mudou para Enviado para avaliação.
Abrir envio no Moodle
Avaliação por commits

Cada cartão Ponto de commit é uma tarefa: faça-a, copie o comando do cartão e rode. A mensagem começa com o código (T1:, T2:…) — é como a correção identifica sua entrega. Um commit por tarefa; pode refazer (vale o mais recente); e não esqueça o git push. Detalhes em Como funciona a avaliação.


Objetivos de aprendizagem​

Ao final você será capaz de:

  • Explicar o modelo do git: working tree → staging → repositório local → remoto.
  • Aplicar a convenção do curso: 1 tarefa = 1 commit, mensagem iniciando com Tn:.
  • Escrever Markdown com fluência: cabeçalhos, ênfase, listas, links, imagens, código, tabelas, citações e sumário com âncoras.
  • Produzir um README.md completo, legível e navegável.
  • Criar branches, fazer merge e resolver um conflito simples.
  • Usar gh para repo, pr, issue, release e api sem sair do terminal.

Material​

  • VS Code (editor). Recomendada a extensão Markdown All in One e o markdownlint para pré-visualizar e revisar o Markdown.
  • git instalado (git --version).
  • GitHub CLI (gh) instalado (gh --version) — série 2.x.
  • Conta no GitHub, membro da organização ELT85B-N21-2026-2.
  • Seu repositório de grupo: lab00-grupo-<sua-letra> (criado no passo acima).
Pré-visualize enquanto escreve

No VS Code, com um arquivo .md aberto, use Ctrl+Shift+V (ou o ícone de lupa no canto superior direito) para ver o Markdown renderizado lado a lado. É a forma mais rápida de conferir cada tarefa antes do commit.

O modelo mental do git​

Um commit é uma fotografia imutável do projeto num instante, com autor, data e mensagem. O git add escolhe o que entra na foto; o git commit tira a foto; o git push envia as fotos para o GitHub, onde o autograder as encontra.

A convenção do curso

Cada tarefa Tn = um commit cuja mensagem começa com Tn:. Exemplo: T1: registra identidade do git. Se precisar corrigir uma tarefa, refaça com um novo commit Tn: — vale sempre o Tn: mais recente. Nunca use push --force no repositório de grupo.

Configuração única vs. rotina de trabalho

Há dois ritmos no git. git config --global (sua identidade) é feito uma única vez por máquina — configura e esquece. Já git add → commit → push é a rotina que você repete a cada tarefa. Não confunda os dois: reconfigurar identidade a cada commit é desperdício; esquecer de commitar/enviar é perder a entrega.

Confira que você está dentro do repositório clonado antes de começar:

Terminal
cd lab00-grupo-a # troque pela letra do seu grupo
git status

Parte 1 — Primeiro commit e o título do README​

Objetivo: provar que sua identidade está correta e criar o README.md com um cabeçalho de nível 1.

Muitos passos desta aula são de runtime (rodam comandos, não editam arquivos "de conteúdo"). Para que o autograder possa checá-los, você salva a evidência da saída em evidencias/*.txt. Crie a pasta e registre a identidade:

Terminal
mkdir -p evidencias
git config --list | grep -E "user\.(name|email)" > evidencias/git-config.txt
cat evidencias/git-config.txt
git add evidencias/git-config.txt
git commit -m "T1: registra identidade do git"
Ponto de commit · T1 (5 pts) #

Salvar evidencias/git-config.txt com user.name e user.email configurados

git add evidencias/git-config.txt && git commit -m "T1: Salvar evidencias/git-config.txt com user.name e user.email configurados" && git push

O # no início de uma linha é um cabeçalho H1 — o título do documento. Crie o README.md com o título e um parágrafo de introdução:

README.md
# lab00 — grupo A

Repositório do grupo A para o Lab 00 (git, GitHub, gh e Markdown).
Terminal
git add README.md
git commit -m "T2: cria README com titulo e introducao"
Ponto de commit · T2 (5 pts) #

Criar README.md com um cabecalho H1 e um paragrafo de introducao

git add README.md && git commit -m "T2: Criar README.md com um cabecalho H1 e um paragrafo de introducao" && git push

Parte 2 — Markdown essencial​

Objetivo: os blocos de construção de qualquer texto em Markdown.

2.1 Cabeçalhos e ênfase​

O número de # define o nível do cabeçalho (H1 a H6). Para ênfase: **negrito**, *itálico* e `código inline` (crases).

README.md (adicione ao final)
## Sobre o grupo

Integrantes: **Fulano da Silva** e _Ciclana Souza_.
Usamos o comando `git status` o tempo todo.

### Contato

Dúvidas: abra uma _issue_ neste repositório.

Resultado renderizado — os # viram títulos de tamanhos diferentes, **...** fica em negrito, *...* em itálico e `...` aparece em fonte monoespaçada.

Terminal
git add README.md
git commit -m "T3: adiciona cabecalhos e enfase ao README"
Ponto de commit · T3 (6 pts) #

Adicionar cabecalhos H2/H3, negrito, italico e codigo inline ao README.md

git add README.md && git commit -m "T3: Adicionar cabecalhos H2/H3, negrito, italico e codigo inline ao README.md" && git push

2.2 Listas​

Três tipos: não-ordenada (-), ordenada (1.) e de tarefas (- [ ] / - [x]). A indentação cria sublistas.

README.md (adicione ao final)
## Ferramentas

- git
- GitHub CLI (gh)
- `gh pr`
- `gh issue`
- VS Code

## Passos para entregar

1. Editar o arquivo
2. `git add`
3. `git commit`

## Checklist

- [x] Repositório clonado
- [ ] README completo
Terminal
git add README.md
git commit -m "T4: adiciona listas ao README"
Ponto de commit · T4 (6 pts) #

Adicionar lista nao-ordenada com sublista, lista ordenada e lista de tarefas ao README.md

git add README.md && git commit -m "T4: Adicionar lista nao-ordenada com sublista, lista ordenada e lista de tarefas ao README.md" && git push

Link: [texto](url). Imagem: ![texto alternativo](url) — a imagem é um link com ! na frente. Um badge é só uma imagem cuja URL gera o selo.

README.md (adicione ao final)
## Referências

- [Documentação oficial do Git](https://git-scm.com/doc)
- [Manual do GitHub CLI](https://cli.github.com/manual/)

![Feito com Markdown](https://img.shields.io/badge/feito%20com-markdown-blue)
Terminal
git add README.md
git commit -m "T5: adiciona links e um badge ao README"
Ponto de commit · T5 (5 pts) #

Adicionar ao menos dois links e uma imagem (badge) ao README.md

git add README.md && git commit -m "T5: Adicionar ao menos dois links e uma imagem (badge) ao README.md" && git push

Parte 3 — Markdown para documentação técnica​

Objetivo: os recursos que tornam um README realmente útil.

3.1 Blocos de código​

Três crases abrem e fecham um bloco; a palavra após as crases define a linguagem (destaque de sintaxe). Isso é essencial para instruções de terminal.

README.md (adicione ao final)
## Como usar

Clone e entre na pasta:

```bash
git clone https://github.com/ELT85B-N21-2026-2/lab00-grupo-a.git
cd lab00-grupo-a
```
Bloco dentro de bloco

Para mostrar um bloco de código dentro de outro (como acima), o bloco externo usa quatro crases. Você raramente precisa disso — mas é útil ao documentar Markdown.

Terminal
git add README.md
git commit -m "T6: adiciona bloco de codigo com destaque de linguagem"
Ponto de commit · T6 (5 pts) #

Adicionar um bloco de codigo com identificacao de linguagem (ex. bash) ao README.md

git add README.md && git commit -m "T6: Adicionar um bloco de codigo com identificacao de linguagem (ex. bash) ao README.md" && git push

3.2 Tabelas​

Colunas separadas por |; a segunda linha (---) separa o cabeçalho e define o alinhamento (:---, :---:, ---:).

README.md (adicione ao final)
## Comandos essenciais

| Comando | O que faz |
| :----------- | :--------------------------- |
| `git status` | mostra o estado da árvore |
| `git add` | move mudanças para o staging |
| `git commit` | grava um commit |

Resultado renderizado:

ComandoO que faz
git statusmostra o estado da árvore
git addmove mudanças para o staging
git commitgrava um commit
Terminal
git add README.md
git commit -m "T7: adiciona uma tabela ao README"
Ponto de commit · T7 (5 pts) #

Adicionar uma tabela Markdown com cabecalho e ao menos duas linhas ao README.md

git add README.md && git commit -m "T7: Adicionar uma tabela Markdown com cabecalho e ao menos duas linhas ao README.md" && git push

3.3 Citações e regra horizontal​

> cria uma citação; três hífens (---) numa linha isolada criam uma régua horizontal que separa seções.

README.md (adicione ao final)
---

> Versione cedo, versione com frequência.

Este repositório segue a convenção `Tn:` de commits do curso.
Terminal
git add README.md
git commit -m "T8: adiciona citacao e regra horizontal"
Ponto de commit · T8 (5 pts) #

Adicionar uma citacao e uma regra horizontal ao README.md

git add README.md && git commit -m "T8: Adicionar uma citacao e uma regra horizontal ao README.md" && git push

Parte 4 — Fluxo de trabalho no git​

Objetivo: ignorar o que não deve ser versionado e integrar trabalho por branches.

4.1 O .gitignore​

Nem tudo entra no git: arquivos temporários do sistema e do editor devem ser ignorados. Crie:

.gitignore
# Sistema operacional
.DS_Store
Thumbs.db
# Temporários
*.tmp
*.log
# VS Code (mantém apenas as extensões recomendadas)
.vscode/*
!.vscode/extensions.json
Terminal
git add .gitignore
git commit -m "T9: adiciona .gitignore"
Ponto de commit · T9 (5 pts) #

Adicionar um .gitignore que ignora arquivos temporarios e de sistema

git add .gitignore && git commit -m "T9: Adicionar um .gitignore que ignora arquivos temporarios e de sistema" && git push

4.2 Branch e merge​

Isole uma mudança num branch, integre-a à main e salve a evidência:

Terminal
git switch -c docs
echo "" >> README.md
echo "## Licença" >> README.md
echo "Uso educacional — ELT85B." >> README.md
git commit -am "wip: secao de licenca no branch docs"

git switch main
git merge docs
git branch --all > evidencias/git-branch.txt
git add evidencias/git-branch.txt
git commit -m "T10: integra branch docs na main"
Ponto de commit · T10 (8 pts) #

Criar branch, fazer merge na main e salvar evidencias/git-branch.txt

git add evidencias/git-branch.txt && git commit -m "T10: Criar branch, fazer merge na main e salvar evidencias/git-branch.txt" && git push

Parte 5 — GitHub pelo terminal (gh)​

Objetivo: operar o repositório remoto sem abrir o navegador.

Terminal
gh auth status 2> evidencias/gh-auth.txt
gh repo view --json name,owner,defaultBranchRef \
--jq '"repo=\(.owner.login)/\(.name) branch=\(.defaultBranchRef.name)"' \
> evidencias/gh-repo.txt
cat evidencias/gh-auth.txt evidencias/gh-repo.txt
git add evidencias/gh-auth.txt evidencias/gh-repo.txt
git commit -m "T11: comprova auth e inspeciona o repo com gh"
evidencias/gh-repo.txt — saída esperada
repo=ELT85B-N21-2026-2/lab00-grupo-a branch=main
Ponto de commit · T11 (5 pts) #

Salvar evidencias/gh-auth.txt (login) e evidencias/gh-repo.txt (owner/nome/branch)

git add evidencias/gh-auth.txt evidencias/gh-repo.txt && git commit -m "T11: Salvar evidencias/gh-auth.txt (login) e evidencias/gh-repo.txt (owner/nome/branch)" && git push
git push de verdade

Até aqui os commits estão no seu repositório local. Envie-os: git push. Confira no GitHub (ou com gh repo view --web) que os commits T1…T11 chegaram.


Projeto integrador — o README completo​

Objetivo: juntar todos os elementos num README.md bem estruturado, com sumário navegável.

Um bom README começa com um sumário (lista de links para âncoras). A âncora de um cabeçalho é o texto em minúsculas, com espaços virando hífens: ## Como usar vira o link [Como usar](#como-usar).

README.md — estrutura final sugerida
# lab00 — grupo A

Repositório do grupo A para o Lab 00.

## Sumário

- [Sobre o grupo](#sobre-o-grupo)
- [Ferramentas](#ferramentas)
- [Como usar](#como-usar)
- [Comandos essenciais](#comandos-essenciais)
- [Licença](#licença)

## Sobre o grupo

...

Revise o README.md para que ele contenha, de forma coerente: título (H1), sumário com âncoras, e seções usando cabeçalhos, listas, links, um badge, um bloco de código e uma tabela.

Terminal
git add README.md
git commit -m "T12: monta o README final com sumario e ancoras"
git push
Ponto de commit · T12 (12 pts) #

Montar o README.md final com sumario de ancoras e todas as secoes integradas

git add README.md && git commit -m "T12: Montar o README.md final com sumario de ancoras e todas as secoes integradas" && git push

Release — publicar uma versão​

O mesmo release que sustenta as tarefas de deploy das próximas aulas:

Terminal
git tag -a v1.0.0 -m "Lab 00 concluido"
git push origin v1.0.0
gh release create v1.0.0 \
--title "Lab 00 — v1.0.0" \
--notes "README em Markdown concluido."
git commit --allow-empty -m "T13: publica release v1.0.0"
git push
Ponto de commit · T13 (8 pts) #

Publicar o release v1.0.0 com gh release create

git commit --allow-empty -m "T13: Publicar o release v1.0.0 com gh release create" && git push

Desafios​

Valem pontos e reforçam o fluxo

Cada desafio é uma tarefa = um commit Tn:. Salve a evidência pedida.

D1 — Melhoria via Pull Request​

Proponha uma melhoria no README por um branch e um PR, em vez de commitar direto na main:

Terminal
git switch -c feature/emojis
echo "" >> README.md
echo "## Status" >> README.md
echo "Projeto concluido. :rocket:" >> README.md
git commit -am "wip: secao de status"
git push -u origin feature/emojis

gh pr create --base main --head feature/emojis \
--title "T14: adiciona secao de status ao README" \
--body "Nova secao Status. Fecha a tarefa T14." \
> evidencias/gh-pr.txt
gh pr merge --merge --delete-branch
git switch main && git pull
git add evidencias/gh-pr.txt
git commit -m "T14: registra o pull request criado"
git push
Ponto de commit · T14 (5 pts) #

Abrir um pull request com gh e salvar a URL em evidencias/gh-pr.txt

git add evidencias/gh-pr.txt && git commit -m "T14: Abrir um pull request com gh e salvar a URL em evidencias/gh-pr.txt" && git push

D2 — Uma issue pelo terminal​

Terminal
gh issue create --title "Adicionar screenshots ao README" \
--body "O README ficaria mais claro com imagens." > evidencias/gh-issue.txt
gh issue list > evidencias/gh-issue-list.txt
git add evidencias/gh-issue.txt evidencias/gh-issue-list.txt
git commit -m "T15: cria issue com gh"
git push
Ponto de commit · T15 (5 pts) #

Abrir uma issue com gh e salvar a URL em evidencias/gh-issue.txt

git add evidencias/gh-issue.txt && git commit -m "T15: Abrir uma issue com gh e salvar a URL em evidencias/gh-issue.txt" && git push

D3 — Resolver um conflito de merge​

Crie um conflito proposital em conflito.txt e resolva-o, mantendo as duas informações (sem os marcadores <<<<<<<):

Terminal
git switch -c ladoA; echo "estilo do README: minimalista" > conflito.txt
git add conflito.txt; git commit -m "wip: ladoA"
git switch main; git switch -c ladoB; echo "estilo do README: detalhado" > conflito.txt
git add conflito.txt; git commit -m "wip: ladoB"
git switch main; git merge ladoA; git merge ladoB # conflito aqui
# edite conflito.txt para: "estilo do README: minimalista e detalhado" e remova os marcadores
git add conflito.txt; git commit -m "T16: resolve conflito de merge"
git push
Ponto de commit · T16 (5 pts) #

Provocar e resolver um conflito de merge, mantendo as duas versoes em conflito.txt

git add conflito.txt && git commit -m "T16: Provocar e resolver um conflito de merge, mantendo as duas versoes em conflito.txt" && git push

D4 — gh api: falar direto com a API​

O gh api chama a REST/GraphQL do GitHub autenticado. Confirme, via API, que seu release existe:

Terminal
gh api repos/{owner}/{repo}/releases/tags/v1.0.0 --jq '.tag_name' \
> evidencias/gh-api.txt
cat evidencias/gh-api.txt # deve imprimir: v1.0.0
git add evidencias/gh-api.txt
git commit -m "T17: consulta o release via gh api"
git push
Ponto de commit · T17 (5 pts) #

Usar gh api para confirmar a tag do release e salvar evidencias/gh-api.txt

git add evidencias/gh-api.txt && git commit -m "T17: Usar gh api para confirmar a tag do release e salvar evidencias/gh-api.txt" && git push

Gabarito​

Spoiler

Tente sozinho antes de abrir. O Markdown e o fluxo git/gh desta aula são pré-requisito de todas as próximas.

Sintaxe Markdown de referência
Referência — sintaxe Markdown
# H1 ## H2 ### H3

**negrito** _italico_ `codigo inline`

- item (lista nao-ordenada)

1. item (lista ordenada)

- [ ] tarefa - [x] feita

[texto](https://url) (link)
![alt](https://url/img.png) (imagem / badge)

​`bash
git status
​`

| A | B | (tabela) |
| --- | --- | -------- |
| 1 | 2 |

> citacao
> --- (regra horizontal)

[Ir para secao](#como-usar) (ancora: minusculas, espacos viram hifen)
Comandos de referência (T1…T17)
Referência — sequência completa
# T1 identidade
mkdir -p evidencias
git config --list | grep -E "user\.(name|email)" > evidencias/git-config.txt
git add evidencias/git-config.txt && git commit -m "T1: registra identidade do git"

# T2..T8 edicoes no README.md (titulo, enfase, listas, links, codigo, tabela, citacao)
# cada bloco -> git add README.md && git commit -m "Tn: ..."

# T9 .gitignore
git add .gitignore && git commit -m "T9: adiciona .gitignore"

# T10 branch + merge
git switch -c docs && echo "## Licenca" >> README.md
git commit -am "wip: licenca"
git switch main && git merge docs
git branch --all > evidencias/git-branch.txt
git add evidencias/git-branch.txt && git commit -m "T10: integra branch docs na main"

# T11 gh auth + repo view
gh auth status 2> evidencias/gh-auth.txt
gh repo view --json name,owner,defaultBranchRef \
--jq '"repo=\(.owner.login)/\(.name) branch=\(.defaultBranchRef.name)"' > evidencias/gh-repo.txt
git add evidencias/gh-auth.txt evidencias/gh-repo.txt
git commit -m "T11: comprova auth e inspeciona o repo com gh"

# T12 README final -> "T12: monta o README final com sumario e ancoras"
# T13 release
git tag -a v1.0.0 -m "Lab 00 concluido" && git push origin v1.0.0
gh release create v1.0.0 --title "Lab 00 — v1.0.0" --notes "Concluido."
git commit --allow-empty -m "T13: publica release v1.0.0"

# T14 gh pr create ... > evidencias/gh-pr.txt -> "T14: ..."
# T15 gh issue create ... > evidencias/gh-issue.txt -> "T15: ..."
# T16 conflito.txt resolvido -> "T16: resolve conflito de merge"
# T17 gh api repos/{owner}/{repo}/releases/tags/v1.0.0 --jq '.tag_name' > evidencias/gh-api.txt

Checklist de entrega​

  • git config com nome e e-mail institucional corretos (T1).
  • Commits com prefixo Tn: na ordem T1…T17.
  • README.md com título, sumário de âncoras, listas, links, badge, bloco de código e tabela (T2–T8, T12).
  • .gitignore presente (T9).
  • Tudo enviado com git push; nada de push --force.
  • Release v1.0.0 publicado e visível em gh release list (T13).
  • Evidências presentes em evidencias/ para os passos de runtime.
Pontuação

Total: 100 pts (o autograder normaliza para 0–10). Base T1…T13 = 80 pts; Desafios T14…T17 = 20 pts.