Git e GitHub para QA Engineers: Um Tutorial Direto ao Ponto

Automação de testes sem Git significa testes que só rodam na sua máquina, sem pipeline de CI, sem code review e sem como colaborar com desenvolvedores. Todo cargo de QA automation exige o mesmo fluxo: criar branch, escrever testes, fazer push, abrir pull request e deixar o CI rodar a suite automaticamente.

O que o Git faz

O Git rastreia mudanças em arquivos ao longo do tempo. Toda mudança que você salva ("commit") é registrada com uma descrição, um timestamp e quem fez. Você pode ver o histórico completo de cada arquivo, voltar a qualquer estado anterior e trabalhar em mudanças sem afetar a codebase principal até estar pronto.

Para QA engineers: o Git é como você salva o trabalho de testes, compartilha com desenvolvedores e roda em pipelines de CI/CD. Você não pode ter um pipeline de CI sem um repositório.

Instalando o Git

Baixe em git-scm.com e instale. Durante a instalação, selecione "Use Git from the command line and also from 3rd-party software."

Rode xcode-select --install no Terminal. O Git já vem incluído.

git --version
# git version 2.44.0

Os 10 comandos que você vai usar 90% do tempo

Configuração inicial (uma vez)

# Dizer ao Git quem você é
git config --global user.name "Seu Nome"
git config --global user.email "voce@exemplo.com"

Iniciando ou clonando um repositório

# Inicializar um novo repositório na pasta atual
git init

# Clonar um repositório existente do GitHub
git clone https://github.com/username/repository-name.git

Para a maioria dos QA engineers, você vai usar clone mais do que init. Você vai entrar em um projeto já existente.

Verificando o que mudou

# Ver quais arquivos têm mudanças
git status

# Ver as mudanças específicas nos arquivos
git diff

Rode git status constantemente. Ele mostra exatamente onde você está.

Salvando seu trabalho (o fluxo principal)

# Adicionar arquivos específicos à staging area (lista "a ser commitado")
git add tests/login.spec.ts
git add pages/LoginPage.ts

# Ou adicionar todos os arquivos alterados
git add .

# Commitar as mudanças staged com uma mensagem
git commit -m "Add login test cases with negative scenarios"

Stage → Commit. Esse é o ciclo de salvar. A mensagem descreve o que você mudou e por quê.

Sincronizando com o repositório remoto (GitHub)

# Pegar as mudanças mais recentes do GitHub
git pull

# Enviar seus commits para o GitHub
git push

Primeiro pull, depois push. Sempre faça pull antes do push para evitar conflitos.

Trabalhando em features (branches)

# Criar uma nova branch e mudar para ela
git checkout -b feature/add-login-tests

# Ver todas as branches
git branch

# Mudar para uma branch existente
git checkout main

Um fluxo de trabalho diário completo

Aqui está como usar o Git na prática em um dia típico:

# 1. Começar o dia — pegar as mudanças mais recentes
git pull

# 2. Criar uma branch para o trabalho
git checkout -b test/payment-flow-automation

# 3. Escrever os testes no VS Code
# ... (tests/payment.spec.ts criado/modificado)

# 4. Verificar o que mudou
git status
# On branch test/payment-flow-automation
# Changes not staged for commit:
#   modified:   tests/payment.spec.ts
# Untracked files:
#   pages/PaymentPage.ts

# 5. Adicionar os arquivos à staging area
git add tests/payment.spec.ts
git add pages/PaymentPage.ts

# 6. Commitar com uma mensagem clara
git commit -m "Add payment flow tests: happy path and card decline scenarios"

# 7. Fazer push para o GitHub
git push origin test/payment-flow-automation

# 8. Abrir um pull request no GitHub (feito no navegador)

GitHub: hospedagem de repositório remoto

O GitHub armazena seu repositório online. As principais coisas que você vai fazer lá:

1. Vá para github.com → New repository

2. Dê um nome

3. Escolha Public ou Private

4. Clique em Create

# Após criar o repositório no GitHub, conecte a pasta local a ele
git remote add origin https://github.com/seuusuario/seu-repo.git
git push -u origin main

Quando você termina o trabalho em uma branch, abre um pull request no GitHub. Isso:

• Mostra as mudanças que você fez
• Permite que colegas revisem e comentem
• Mescla suas mudanças na branch main após aprovação

Para QA engineers em um time: seu código de testes passa pelo mesmo processo de revisão que o código dos desenvolvedores. Abre um PR, pede revisão, faz merge.

.gitignore: o que não rastrear

Alguns arquivos não devem ir para o Git: output de build, segredos, node_modules. Crie um arquivo .gitignore na raiz do repositório:

# Node modules (sempre ignorado — instale com npm install)
node_modules/

# Resultados e relatórios de testes do Playwright
test-results/
playwright-report/

# Arquivos de ambiente que podem conter segredos
.env
.env.local

# Arquivos de SO
.DS_Store
Thumbs.db

O npm init playwright@latest cria um .gitignore automaticamente. Verifique o que está nele antes de commitar.

Branches: por que importam para QA

Branches permitem que várias pessoas trabalhem simultaneamente sem pisar umas nas outras. Convenções de nomenclatura padrão:

main               # código estável, pronto para produção
feature/add-search # nova feature sendo desenvolvida
bugfix/login-error # bug sendo corrigido
test/checkout-flow # novo teste sendo escrito

O padrão usado pela maioria dos times:

1. A branch main é sempre estável

2. Todos criam branches de feature/test para o trabalho

3. O trabalho é revisado em pull requests

4. Mudanças aprovadas fazem merge na main

5. CI/CD roda automaticamente quando mudanças chegam na main

Como QA engineer, você vai criar branches para novas suites de testes, atualizações de testes e reproduções de bugs.

Conflitos de merge: o que são e como resolver

Um conflito de merge acontece quando duas pessoas mudaram a mesma parte do mesmo arquivo e o Git não consegue combiná-los automaticamente.

<<<<<<< HEAD
await expect(page.getByText('Success')).toBeVisible();
=======
await expect(page.getByRole('alert')).toHaveText('Success');
>>>>>>> feature/update-assertions

A seção <<<<<<< HEAD é a sua versão. A seção >>>>>>> feature/update-assertions é a versão que está chegando. Você precisa escolher uma (ou combiná-las manualmente), deletar os marcadores de conflito e fazer commit.

A maioria dos conflitos em repositórios de testes é fácil de resolver. Acontecem mais em arquivos compartilhados como playwright.config.ts ou arquivos de Page Object que várias pessoas mexem.

Git log: entendendo o histórico

# Ver commits recentes
git log --oneline
# a3f2c1d Add payment tests
# b7e9a04 Fix login page locator after UI update
# c2d1f8e Add item creation test with validation scenarios

# Ver mudanças em um commit específico
git show a3f2c1d

# Ver quem modificou cada linha de um arquivo por último
git blame tests/login.spec.ts

GitHub Actions: seu pipeline de CI

Com os testes no GitHub, o GitHub Actions pode rodá-los automaticamente a cada push. Um arquivo de workflow básico:

# .github/workflows/playwright.yml
name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

Esse é o arquivo que o npm init playwright@latest oferece criar para você. Com ele no repositório, o GitHub roda seus testes a cada push e pull request. O artigo de CI/CD cobre isso em detalhes.

Cheat sheet de comandos

# Setup
git config --global user.name "Nome"
git config --global user.email "email"

# Diário
git status              # ver o que mudou
git pull                # pegar o mais recente do remoto
git add arquivo.ts      # adicionar um arquivo à staging
git add .               # adicionar todos os arquivos alterados
git commit -m "mensagem" # salvar mudanças staged
git push                # enviar para o remoto

# Branches
git checkout -b nome-da-branch  # criar e mudar para branch
git checkout main               # mudar para main
git branch                      # listar branches
git merge nome-da-branch        # fazer merge da branch na atual

# Histórico
git log --oneline               # commits recentes
git diff                        # mudanças não staged
git show hash-do-commit         # mudanças em um commit

FAQ

Os dois funcionam. O VS Code tem suporte integrado a Git (o painel Source Control) que cobre a maioria das operações diárias sem linha de comando. O GitHub Desktop é outra opção. Vale aprender a linha de comando porque você vai encontrá-la em scripts de CI/CD e servidores remotos, mas começar com uma interface gráfica está ótimo.

Git é o software de controle de versão que roda localmente. GitHub é um site que hospeda repositórios Git remotamente. GitLab e Bitbucket são alternativas ao GitHub. O Git funciona sem o GitHub; o GitHub armazena e compartilha seus repositórios Git.

Seja específico. "Add login tests" é fraco. "Add negative login tests: wrong password, empty fields, SQL injection" é útil. Uma boa mensagem de commit responde: o que mudou e por quê (não como; o código mostra como).

Calma. Se não fez push ainda:

git reset HEAD~1  # desfaz o último commit, mantém as mudanças
git checkout -b minha-branch  # cria uma branch adequada
git add .
git commit -m "mensagem"

Se já fez push e o time usa uma branch main protegida, fale com o tech lead. Nunca faça force-push na main sem consenso do time.

Sim, se você fez commit dele antes:

git checkout HEAD -- caminho/para/arquivo.ts

Esse é um dos recursos mais úteis do Git. Você consegue recuperar qualquer coisa que já foi commitada.