Git & GitHub:
do zero ao mercado de trabalho

O problema que o Git resolve

Imagine que você está escrevendo um trabalho importante. Com medo de perder algo, você começa a salvar cópias: trabalho.doc, trabalho-final.doc, trabalho-final-v2.doc, trabalho-final-AGORA-VAI.doc. Em pouco tempo você não sabe mais qual é a versão certa, o que mudou entre elas, nem consegue juntar as alterações que você fez com as que um colega fez.

Agora imagine isso com milhares de arquivos de código e uma equipe de 10 pessoas mexendo no mesmo projeto ao mesmo tempo. É o caos — e é exatamente esse caos que um sistema de controle de versão (VCS, de Version Control System) elimina.

Um sistema de controle de versão registra toda a história do projeto: cada alteração, quem fez, quando fez e por quê. Com ele você pode:

• Voltar para qualquer versão anterior do projeto, a qualquer momento;
• Ver exatamente o que mudou entre duas versões, linha por linha;
• Trabalhar em equipe no mesmo código sem sobrescrever o trabalho dos outros;
• Testar ideias em paralelo (branches) sem quebrar a versão principal;
• Descobrir quando e onde um bug foi introduzido.

Git ≠ GitHub

Essa é uma das primeiras coisas que entrevistadores testam, e muita gente confunde:

Resumindo: Git é a ferramenta, GitHub é o serviço que usa essa ferramenta e adiciona colaboração por cima — Pull Requests, issues, revisão de código, automações (Actions) e a parte "rede social" que virou vitrine profissional.

Como o Git pensa: fotografias, não diferenças

Uma ideia central que vai facilitar tudo daqui em diante: o Git enxerga seu projeto como uma sequência de fotografias (snapshots). Cada vez que você "salva" no Git (um commit), ele tira uma foto de como todos os arquivos estão naquele momento e guarda uma referência para essa foto.

Cada foto recebe um código único chamado hash (algo como a1f9e02... — repare no sumário desta apostila!). Esse código identifica o commit para sempre. A história do projeto é a corrente dessas fotos, e você pode "viajar no tempo" para qualquer uma delas.

Instalando o Git

• Windows: baixe em git-scm.com/downloads e instale. O instalador inclui o Git Bash, um terminal que aceita os mesmos comandos de Linux/Mac — use-o para seguir esta apostila.
• macOS: no terminal, rode xcode-select --install ou instale via Homebrew: brew install git.
• Linux (Ubuntu/Debian): sudo apt update && sudo apt install git.

Para conferir se deu certo:

git --version
git version 2.45.1

Configurando sua identidade (obrigatório)

Todo commit registra autor e e-mail. Configure uma única vez com a flag --global, e o Git usa em todos os seus projetos:

git config --global user.name "Seu Nome"
git config --global user.email "seu-email@exemplo.com"
# define a branch inicial como "main" (padrão do mercado)
git config --global init.defaultBranch main
# conferir tudo o que está configurado
git config --list

Criando sua conta no GitHub

1. Acesse github.com e clique em Sign up.
2. Escolha bem o nome de usuário: ele vira sua URL profissional (github.com/seu-nome) e vai em currículo e LinkedIn. Prefira algo limpo, como mariasilva ou maria-silva-dev. Evite apelidos difíceis de levar a sério.
3. Ative a autenticação em dois fatores (2FA) em Settings → Password and authentication.

Conectando via SSH (o jeito profissional)

O GitHub não aceita senha para enviar código. As duas opções são token pessoal (HTTPS) ou chave SSH. Empresas usam SSH: você configura uma vez e nunca mais digita credenciais. A chave tem duas partes — a privada (fica só na sua máquina, nunca compartilhe) e a pública (você cadastra no GitHub).

# 1. gerar o par de chaves (pressione Enter nas perguntas)
ssh-keygen -t ed25519 -C "seu-email@exemplo.com"
# 2. mostrar a chave PÚBLICA e copiar a saída inteira
cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1... seu-email@exemplo.com
# 3. no GitHub: Settings → SSH and GPG keys → New SSH key → cole e salve
# 4. testar a conexão
ssh -T git@github.com
Hi maria-silva! You've successfully authenticated.

As três áreas do Git

Quase toda confusão de iniciante nasce de não entender que o Git organiza seu trabalho em três lugares:

1. Working Directory (diretório de trabalho): a pasta do projeto, os arquivos que você edita normalmente.
2. Staging Area (área de preparação, ou "index"): uma "bandeja" onde você coloca apenas as mudanças que vão entrar na próxima fotografia. É o que permite commits organizados: você pode alterar 10 arquivos e commitar só 3.
3. Repository (repositório, a pasta .git): o cofre com todas as fotografias (commits) já tiradas.

Mão na massa: criando um repositório

# criar uma pasta e entrar nela
mkdir meu-projeto && cd meu-projeto
# transformar a pasta em um repositório Git
git init
Initialized empty Git repository in .../meu-projeto/.git/
# criar um arquivo qualquer
echo "# Meu Projeto" > README.md
# perguntar ao Git: como estão as coisas?
git status
On branch main
Untracked files:
        README.md

git status é o comando que você mais vai digitar na vida. Ele mostra em que branch você está, o que foi modificado, o que está na staging area e o que o Git ainda nem conhece (untracked). Na dúvida, rode git status.

git add e git commit

# colocar o arquivo na staging area
git add README.md
# ou adicionar TUDO que mudou (use com consciência)
git add .
# tirar a fotografia com uma mensagem descritiva
git commit -m "Adiciona README com descrição do projeto"
[main (root-commit) a1f9e02] Adiciona README com descrição do projeto
 1 file changed, 1 insertion(+)

Vendo a história e as diferenças

# histórico completo
git log
# versão resumida, uma linha por commit (a mais usada no dia a dia)
git log --oneline
c92ab55 Corrige link quebrado no README
a1f9e02 Adiciona README com descrição do projeto
# com o desenho das branches
git log --oneline --graph --all
# o que mudou e ainda NÃO está na staging area
git diff
# o que está na staging area (o que entrará no commit)
git diff --staged

.gitignore: o que nunca deve entrar no repositório

Nem tudo deve ser versionado: dependências (node_modules/), arquivos gerados (dist/), configurações da IDE e, principalmente, segredos (.env com senhas e tokens). Crie um arquivo chamado .gitignore na raiz do projeto:

node_modules/
dist/
.env
*.log
.DS_Store

O mapa do "socorro"

git reset: soft, mixed e hard

git reset move a branch para um commit anterior. O que muda entre os modos é o que acontece com as suas alterações:

• git reset --soft HEAD~1 — desfaz o commit, mas mantém tudo na staging area. Ótimo para "recommitar" melhor.
• git reset HEAD~1 (mixed, o padrão) — desfaz o commit e o add; as mudanças continuam nos arquivos.
• git reset --hard HEAD~1 — desfaz o commit e apaga as alterações. Use com muito cuidado.

HEAD é um ponteiro para "onde você está agora" (normalmente, o último commit da branch atual). HEAD~1 significa "um commit antes do atual"; HEAD~3, três antes.

git stash: a gaveta de rascunhos

Você está no meio de uma tarefa e chega um chamado urgente para corrigir um bug em outra branch. Seu trabalho não está pronto para um commit. O stash guarda tudo em uma gaveta e deixa o projeto limpo:

# guardar o trabalho em andamento (com uma etiqueta)
git stash push -m "formulário de cadastro pela metade"
# ... resolve a urgência em outra branch ...
# listar o que há na gaveta
git stash list
stash@{0}: On main: formulário de cadastro pela metade
# recuperar o trabalho (e remover da gaveta)
git stash pop

O que é uma branch

Uma branch (ramo) é uma linha do tempo independente do projeto. A branch principal costuma se chamar main. Quando você cria uma branch, é como copiar a linha do tempo a partir do ponto atual: você pode experimentar, quebrar e refazer à vontade — a main continua intacta.

Na prática de mercado, ninguém desenvolve direto na main. Cada tarefa (nova funcionalidade, correção de bug) ganha sua própria branch, que depois é integrada via Pull Request (capítulo 9).

Comandos essenciais

# listar branches (o * indica onde você está)
git branch
# criar uma branch E já mudar para ela (forma moderna)
git switch -c feature/login
# ... trabalha, faz commits normalmente ...
# voltar para a main
git switch main
# trazer as mudanças da feature para a main
git merge feature/login
# apagar a branch depois de integrada
git branch -d feature/login

Você também verá git checkout -b nome em tutoriais antigos — faz o mesmo que git switch -c. O checkout ainda funciona, mas switch (trocar de branch) e restore (restaurar arquivos) foram criados para separar responsabilidades e são o padrão atual.

Fast-forward vs. merge commit

• Fast-forward: se a main não mudou desde que a branch nasceu, o Git só "anda com o ponteiro" para frente. Sem commit extra.
• Merge commit (three-way merge): se as duas branches avançaram, o Git cria um commit especial com dois pais, unindo as linhas do tempo. É o losango que você vê nos gráficos.

Conflitos: o rito de passagem

Conflito acontece quando duas branches alteram as mesmas linhas do mesmo arquivo. O Git não sabe qual versão vale — e pede a sua decisão. Não é erro, é rotina de trabalho em equipe.

git merge feature/promocao
Auto-merging precos.js
CONFLICT (content): Merge conflict in precos.js
Automatic merge failed; fix conflicts and then commit the result.

# o arquivo fica marcado assim:
<<<<<<< HEAD
const desconto = 0.10;   // versão da SUA branch
=======
const desconto = 0.15;   // versão da OUTRA branch
>>>>>>> feature/promocao

Para resolver: (1) abra o arquivo, (2) escolha o que fica (uma versão, a outra, ou uma combinação), (3) apague as linhas de marcação <<<<<<<, ======= e >>>>>>>, (4) rode git add arquivo e git commit. Se quiser abortar tudo e voltar como estava: git merge --abort.

Rebase: reescrevendo a base da branch

Enquanto o merge junta duas linhas do tempo criando um commit de união, o rebase faz outra coisa: pega os seus commits e os "replanta" em cima da versão mais nova da outra branch, como se você tivesse começado o trabalho hoje. O resultado é um histórico em linha reta, sem losangos.

# na sua branch de trabalho:
git switch feature/relatorio
# replantar seus commits sobre a main atualizada
git rebase main
Successfully rebased and updated refs/heads/feature/relatorio.

Rebase interativo: faxina antes do Pull Request

Durante o trabalho, é normal acumular commits como "wip", "conserta teste", "agora sim". Antes de abrir o PR, o rebase interativo permite juntar, reordenar, renomear ou apagar commits:

git rebase -i HEAD~3
# abre um editor com a lista:
pick 3ac1f22 Cria tela de relatório
squash 8bd0e91 wip
squash 91c7a04 conserta teste
# troque "pick" por "squash" (ou "s") nos commits que devem
# ser fundidos no de cima; salve e edite a mensagem final.

Cherry-pick: transplantar um commit específico

Precisa levar um commit de uma branch para outra, sem levar o resto? É o caso clássico de uma correção que precisa ir agora para produção:

git switch main
git cherry-pick 8bd0e91
[main f6d2c14] Corrige cálculo de imposto

Reflog: a máquina do tempo de emergência

"Fiz um reset --hard e perdi tudo!" — quase nunca é verdade. O reflog registra todos os lugares onde o HEAD esteve, incluindo commits que "sumiram" do log. Ele é sua rede de segurança:

git reflog
e4b8a90 HEAD@{0}: reset: moving to HEAD~2
f6d2c14 HEAD@{1}: commit: Finaliza relatório mensal
# achou o commit! basta voltar para ele:
git reset --hard f6d2c14

Local × remoto

Até agora tudo viveu na sua máquina. Um remoto é uma cópia do repositório hospedada em outro lugar — no nosso caso, no GitHub. Por convenção, o remoto principal se chama origin. O fluxo é: você trabalha localmente e sincroniza com o remoto de tempos em tempos.

Caminho 1: projeto local → GitHub

# 1. crie um repositório vazio no GitHub (botão "New repository")
# 2. conecte o local ao remoto
git remote add origin git@github.com:maria-silva/meu-projeto.git
# 3. envie a branch main (o -u cria o "vínculo" para os próximos pushes)
git push -u origin main
# daqui em diante, basta:
git push

Caminho 2: GitHub → sua máquina (clone)

git clone git@github.com:empresa/sistema-vendas.git
Cloning into 'sistema-vendas'...
cd sistema-vendas
# o clone já vem com o remoto "origin" configurado
git remote -v
origin  git@github.com:empresa/sistema-vendas.git (fetch)
origin  git@github.com:empresa/sistema-vendas.git (push)

pull vs. fetch

• git fetch — baixa as novidades do remoto, mas não mexe nos seus arquivos. Você olha primeiro (git log origin/main) e integra quando quiser.
• git pull — faz o fetch e já integra (por padrão, com merge) na sua branch atual. É o fetch + merge em um passo.

Rotina de mercado: antes de começar o dia e antes de qualquer push, rode git pull na branch base. Isso evita a maior parte dos conflitos e do clássico erro rejected: non-fast-forward (que significa: o remoto tem commits que você ainda não tem — puxe antes de empurrar).

Anatomia de um repositório profissional

• README.md — o cartão de visitas. É a primeira coisa que qualquer pessoa (e recrutador) vê. Um bom README responde: o que o projeto faz, como instalar, como usar e como contribuir. Markdown básico: # títulos, **negrito**, `código`, - listas, ![imagem](url).
• LICENSE — sem licença, ninguém pode legalmente usar seu código. Para portfólio, a MIT é a escolha padrão: curta e permissiva. O GitHub cria pra você em "Add file → Create new file → LICENSE".
• .gitignore — já vimos no capítulo 3; o GitHub oferece modelos por linguagem ao criar o repo.
• Issues — o sistema de tarefas/bugs do repositório. Em open source, é onde tudo começa; em times, muitas empresas usam para rastrear trabalho.
• Releases e tags — versões "carimbadas" do projeto (ex.: v1.2.0). Veremos versionamento semântico no capítulo 10.

Fork: sua cópia de um projeto alheio

Um fork é uma cópia de um repositório de outra pessoa para a sua conta. É a base da contribuição em open source, já que você não tem permissão de push no projeto original:

1. Clique em Fork no repositório original (upstream);
2. Clone o seu fork para a máquina;
3. Crie uma branch, faça a alteração, dê push para o seu fork;
4. Abra um Pull Request do seu fork para o projeto original.

# adicionar o projeto original como segundo remoto
git remote add upstream git@github.com:projeto-original/repo.git
# puxar as novidades do original para a sua main
git fetch upstream
git switch main
git merge upstream/main
git push origin main

O que é um Pull Request

Um Pull Request (PR) é um pedido formal: "minha branch está pronta — por favor, revisem e integrem na main". Ele empacota seus commits, mostra o diff completo, abre espaço para discussão linha a linha e dispara verificações automáticas (CI, capítulo 11). Nada entra na main de uma empresa séria sem passar por um PR aprovado.

O fluxo completo, do início ao fim

# 1. partir sempre da main atualizada
git switch main && git pull
# 2. criar a branch da tarefa
git switch -c feature/exportar-pdf
# 3. trabalhar em commits pequenos e claros
git add . && git commit -m "feat: adiciona botão de exportar PDF"
# 4. publicar a branch
git push -u origin feature/exportar-pdf
# 5. abrir o PR no GitHub (ele mesmo sugere o botão
#    "Compare & pull request" após o push)
# 6. responder à revisão: novos commits na mesma branch
#    atualizam o PR automaticamente
# 7. aprovado → merge → apagar a branch

Escrevendo um PR que facilita o "sim"

• Título claro, no mesmo espírito das mensagens de commit: "Adiciona exportação de relatório em PDF".
• Descrição com contexto: o que muda, por quê, como testar. Times usam templates com seções (Contexto / O que foi feito / Como testar / Screenshots).
• PRs pequenos. Um PR de 200 linhas é revisado em minutos; um de 2.000 vira gargalo e fonte de bugs. Se a tarefa é grande, fatie em PRs sequenciais.
• Revise-se antes: abra a aba "Files changed" e leia seu próprio diff. Você vai achar coisas — todo mundo acha.

As opções de merge no GitHub

Code review: etiqueta profissional

Recebendo revisão: comentários são sobre o código, não sobre você. Agradeça boas observações, argumente tecnicamente quando discordar e nunca leve para o pessoal — saber receber feedback é avaliado tanto quanto saber programar.

Fazendo revisão: seja específico e gentil ("que tal extrair essa lógica para uma função? ficaria testável" em vez de "isso está ruim"). Elogie o que estiver bom. Pergunte antes de afirmar. Marque o que é bloqueante e o que é sugestão (nit: é a convenção para detalhes opcionais).

GitHub Flow: o fluxo mais comum

Simples e dominante em times ágeis e produtos web com deploy contínuo:

1. A main está sempre pronta para produção;
2. Toda tarefa nasce em uma branch a partir da main;
3. Abre-se um PR cedo, discute-se, o CI roda;
4. Aprovado → merge na main → deploy (muitas vezes automático).

Git Flow: o clássico com releases

Criado para softwares com versões planejadas (apps desktop/mobile, sistemas corporativos com janelas de release). Usa branches de papéis fixos:

Trunk-based development é o terceiro modelo que você ouvirá: branches pequenas que vivem no máximo 1–2 dias (ou commits direto no trunk, protegidos por feature flags), integração contínua agressiva. É o favorito de empresas com engenharia madura e deploys diários.

Conventional Commits

Um padrão de mensagens que muitas vagas citam por nome. Formato: tipo(escopo opcional): descrição:

feat: adiciona filtro por data no relatório
fix: corrige divisão por zero no cálculo de média
docs: atualiza instruções de instalação no README
refactor: extrai regras de frete para módulo próprio
test: cobre casos de CPF inválido
chore: atualiza dependências de desenvolvimento
feat!: remove suporte à API v1 (breaking change)

Além de legibilidade, o padrão permite automatizar changelog e número de versão — ferramentas leem os prefixos e decidem a próxima versão sozinhas.

Versionamento semântico (SemVer) e tags

Versões no formato MAJOR.MINOR.PATCH — ex.: 2.4.1:

• MAJOR — mudanças incompatíveis (quebra quem usa);
• MINOR — funcionalidade nova compatível;
• PATCH — correção de bug compatível.

# criar uma tag anotada no commit atual
git tag -a v1.0.0 -m "Primeira versão estável"
# enviar as tags ao GitHub
git push origin --tags
# no GitHub: Releases → "Draft a new release" → escolher a tag

O que são CI e CD

• CI (Integração Contínua): a cada push/PR, um robô roda automaticamente testes, lint e build. Código quebrado é barrado antes de entrar na main.
• CD (Entrega/Deploy Contínuo): se tudo passou, o código é empacotado e publicado automaticamente (site no ar, pacote no registro, app na loja).

GitHub Actions é o serviço de automação embutido no GitHub. Você descreve workflows em arquivos YAML dentro de .github/workflows/, e o GitHub executa em máquinas na nuvem (runners) quando certos eventos acontecem (push, PR, agendamento...).

Seu primeiro workflow

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  testes:
    runs-on: ubuntu-latest
    steps:
      - name: Baixar o código
        uses: actions/checkout@v4

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

      - name: Instalar dependências
        run: npm ci

      - name: Rodar testes
        run: npm test

Traduzindo o vocabulário:

• on — os eventos que disparam o workflow (aqui: push na main e qualquer PR);
• jobs — blocos de trabalho; rodam em paralelo por padrão, cada um em uma máquina limpa;
• steps — os passos do job, em sequência;
• uses — reutiliza uma action pronta do marketplace (ex.: actions/checkout baixa seu código);
• run — executa um comando de terminal.

Depois do push desse arquivo, a aba Actions do repositório mostra cada execução, com logs passo a passo. Em PRs, o resultado aparece como um check verde ✓ ou vermelho ✗ — e com proteção de branch, PR com check vermelho não pode ser mergeado.

Segredos e deploy

Tokens e senhas usados pelos workflows ficam em Settings → Secrets and variables → Actions — nunca no YAML. No workflow, você os acessa como ${{ secrets.NOME_DO_SEGREDO }}. Um exemplo comum de CD para portfólio é publicar um site estático no GitHub Pages:

  deploy:
    needs: testes
    runs-on: ubuntu-latest
    permissions:
      pages: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/upload-pages-artifact@v3
        with:
          path: ./dist
      - uses: actions/deploy-pages@v4

O needs: testes encadeia os jobs: o deploy só roda se os testes passarem. Esse é o coração do CD.

git bisect: caça ao bug por busca binária

"Funcionava semana passada e agora não funciona mais." Em vez de ler 200 commits, o bisect encontra o commit culpado testando pontos médios — em 200 commits, ~8 testes bastam:

git bisect start
git bisect bad            # o commit atual está quebrado
git bisect good v1.3.0    # nessa versão funcionava
Bisecting: 100 revisions left to test after this
# o Git te leva a um commit do meio; teste e responda:
git bisect good  # ou: git bisect bad
# ...repita até:
7a3e581 is the first bad commit
git bisect reset          # encerra e volta ao normal

git blame: quem, quando e por quê

git blame arquivo.js mostra, para cada linha, o commit, o autor e a data da última alteração. Apesar do nome, o uso profissional não é apontar culpados — é entender o contexto: você acha o commit, lê a mensagem e o PR associado, e descobre por que aquela linha estranha existe antes de mexer nela.

Hooks: automação na sua máquina

Hooks são scripts que o Git executa em momentos-chave. Os mais usados:

• pre-commit — roda antes de cada commit; se falhar, o commit é abortado. Uso típico: lint e formatação automática.
• commit-msg — valida a mensagem (ex.: exigir Conventional Commits).
• pre-push — roda os testes antes de enviar ao remoto.

Os scripts vivem em .git/hooks/, mas como essa pasta não é versionada, times usam gerenciadores como Husky (JavaScript) ou pre-commit (Python) para compartilhar hooks pelo repositório — nomes que valem conhecer para entrevistas.

Miscelânea que aparece no trabalho

Como um recrutador lê seu perfil

Quando alguém abre github.com/voce, a leitura leva poucos minutos e segue mais ou menos esta ordem:

1. Foto, nome e bio — parece um profissional ou uma conta abandonada?
2. README de perfil — quem é você, o que faz, o que estuda;
3. Projetos fixados (pinned) — seus 6 melhores trabalhos, escolhidos por você;
4. Gráfico de contribuições — constância (não é preciso ser verde todo dia; buracos de meses é que chamam atenção);
5. Dentro de 1 ou 2 repositórios — README, organização, mensagens de commit, testes, CI.

README de perfil

Crie um repositório com o mesmo nome do seu usuário (ex.: maria-silva/maria-silva) contendo um README.md — o GitHub o exibe no topo do seu perfil. Estrutura que funciona:

## Olá! Eu sou a Maria 👋

Desenvolvedora backend em formação, focada em Node.js e SQL.
Atualmente estudando testes automatizados e Docker.

### 🔨 Projetos em destaque
- [api-financas](link) — API REST de controle financeiro (Node, PostgreSQL, CI)
- [meu-portfolio](link) — site pessoal com deploy automático no GitHub Pages

### 📫 Contato
LinkedIn: linkedin.com/in/maria-silva · Email: maria@exemplo.com

Menos é mais: evite encher de badges coloridos de toda tecnologia que você já viu na vida. Três projetos bons dizem mais do que 40 selos.

O que faz um repositório de portfólio ser forte

• README completo: o que é, screenshot/GIF funcionando, como rodar, tecnologias, o que você aprendeu;
• Histórico limpo: Conventional Commits, nada de "aaa" e "teste final 2";
• CI verde: badge de testes passando (capítulo 11);
• Issues e PRs usados de verdade: mesmo sozinho, trabalhe via branch + PR — mostra método;
• Projeto que resolve algo real: um conversor que você mesmo usa vale mais que o 500º clone de tutorial.

Trilha de prática sugerida

1. Dias 1–7 · músculo básico: versione tudo o que estudar. Meta: 20+ commits com boas mensagens, usando status, diff e log sem pensar.
2. Dias 8–14 · branches: nunca mais commite direto na main, nem sozinho. Toda mudança = branch + PR no seu próprio repo. Provoque e resolva 3 conflitos.
3. Dias 15–21 · automação: adicione testes e um workflow de CI a um projeto; ative proteção de branch; publique uma Release com tag.
4. Dias 22–30 · mundo real: monte o README de perfil (cap. 13) e faça sua primeira contribuição open source, ainda que em documentação.

Recursos que valem seu tempo

• Pro Git (livro oficial, gratuito, em português) — a referência definitiva;
• Learn Git Branching — jogo visual para treinar branches, merge e rebase;
• Documentação do GitHub em português — inclusive guias de Actions;
• Oh Shit, Git!?! — receitas de emergência para quando algo der errado;
• Conventional Commits — a especificação oficial do padrão de mensagens.

Boa jornada — e lembre-se do mantra desta apostila: na dúvida, git status. 🚀