Git y GitHub para QA Engineers: Un Tutorial Sin Relleno

La automatización de tests sin Git significa tests que solo corren en tu máquina, sin pipeline de CI, sin revisión de código y sin forma de colaborar con los desarrolladores. Todos los roles de automatización QA requieren el mismo flujo de trabajo: crear una rama desde main, escribir los tests, subirlos a GitHub, abrir un pull request y dejar que CI ejecute el suite automáticamente. Esta guía cubre los 10 comandos que usarás a diario, el flujo de trabajo basado en ramas que siguen la mayoría de los equipos, y cómo conectar un pipeline de GitHub Actions a tu repositorio de tests.

Qué hace Git

Git rastrea los cambios de archivos a lo largo del tiempo. Cada cambio que guardas ("commit") se registra con una descripción, una marca de tiempo y quién lo hizo. Puedes ver el historial completo de cada archivo, volver a cualquier estado anterior, y trabajar en cambios sin afectar el codebase principal hasta que estés listo.

Para ingenieros QA: Git es cómo guardas el trabajo de tests, lo compartes con los desarrolladores, y lo ejecutas en pipelines de CI/CD. No puedes tener un pipeline de CI sin un repositorio.

Instalar Git

Windows

Descarga desde git-scm.com e instala. Durante la instalación, selecciona "Use Git from the command line and also from 3rd-party software."

Mac

Ejecuta xcode-select --install en la Terminal. Git está incluido.

Verificar

git --version
# git version 2.44.0

Los 10 comandos que usarás el 90% del tiempo

Configuración inicial (una vez)

# Decirle a Git quién sos
git config --global user.name "Tu Nombre"
git config --global user.email "tu@ejemplo.com"

Iniciar o clonar un repositorio

# Inicializar un nuevo repositorio en la carpeta actual
git init

# Clonar un repositorio existente desde GitHub
git clone https://github.com/username/nombre-repositorio.git

Para la mayoría de los ingenieros QA, usarás clone más que init. Te vas a unir a un proyecto existente.

Ver qué cambió

# Ver qué archivos tienen cambios
git status

# Ver los cambios específicos en los archivos
git diff

Ejecuta git status constantemente. Te muestra exactamente dónde estás.

Guardar tu trabajo (el flujo central)

# Preparar archivos específicos (agregarlos a la lista "para hacer commit")
git add tests/login.spec.ts
git add pages/LoginPage.ts

# O preparar todos los archivos con cambios
git add .

# Confirmar los cambios preparados con un mensaje
git commit -m "Agregar casos de prueba de login con escenarios negativos"

Preparar → Confirmar. Ese es el ciclo de guardado. El mensaje describe qué cambiaste y por qué.

Sincronizar con el remoto (GitHub)

# Obtener los últimos cambios de GitHub
git pull

# Enviar tus commits a GitHub
git push

Trabajar en funcionalidades (ramas)

# Crear una nueva rama y cambiar a ella
git checkout -b feature/agregar-tests-login

# Ver todas las ramas
git branch

# Cambiar a una rama existente
git checkout main

Un flujo de trabajo diario completo

Así se ve usar Git en la práctica en un día típico:

# 1. Empezar el día: obtener los últimos cambios
git pull

# 2. Crear una rama para tu trabajo
git checkout -b test/automatizacion-flujo-pago

# 3. Escribir los tests en VS Code
# ... (tests/payment.spec.ts creado/modificado)

# 4. Verificar qué cambió
git status
# On branch test/automatizacion-flujo-pago
# Changes not staged for commit:
#   modified:   tests/payment.spec.ts
# Untracked files:
#   pages/PaymentPage.ts

# 5. Preparar los archivos
git add tests/payment.spec.ts
git add pages/PaymentPage.ts

# 6. Confirmar con un mensaje claro
git commit -m "Agregar tests de flujo de pago: camino feliz y escenarios de tarjeta rechazada"

# 7. Subir a GitHub
git push origin test/automatizacion-flujo-pago

# 8. Abrir un pull request en GitHub (se hace en el navegador)

GitHub: hospedaje de repositorios remotos

GitHub almacena tu repositorio online. Las cosas principales que harás en GitHub:

Crear un repositorio

1. Ir a github.com → New repository

2. Darle un nombre

3. Elegir público o privado

4. Hacer clic en Create

Conectar tu repo local con GitHub

# Después de crear el repo en GitHub, conectá tu carpeta local a él
git remote add origin https://github.com/tuusuario/tu-repo.git
git push -u origin main

Pull requests (PRs)

Cuando terminas el trabajo en una rama, abres un pull request en GitHub. Esto muestra los cambios que hiciste, deja que los compañeros de equipo revisen y comenten, y fusiona tus cambios en la rama main después de la aprobación.

Para ingenieros QA en un equipo: el código de tus tests pasa por el mismo proceso de revisión que el código de los desarrolladores. Abres un PR, lo revisan, lo fusionas.

.gitignore: qué no rastrear

Algunos archivos no deben ir a Git: output del build, secretos, node_modules. Crea un archivo .gitignore en la raíz de tu repositorio:

# Node modules (siempre ignorados: instalá con npm install en su lugar)
node_modules/

# Resultados y reportes de tests de Playwright
test-results/
playwright-report/

# Archivos de entorno que pueden contener secretos
.env
.env.local

# Archivos del sistema operativo
.DS_Store
Thumbs.db

Ramas: por qué importan para QA

Las ramas permiten que varias personas trabajen simultáneamente sin pisarse. Convenciones estándar de nombres:

main               # código estable, listo para producción
feature/agregar-busqueda  # nueva funcionalidad en desarrollo
bugfix/error-login        # bug que se está corrigiendo
test/flujo-checkout       # test nuevo que se está escribiendo

El patrón que usa la mayoría de los equipos:

1. La rama main es siempre estable

2. Todos crean ramas de feature/test para su trabajo

3. El trabajo se revisa en pull requests

4. Los cambios aprobados se fusionan en main

5. CI/CD corre automáticamente cuando los cambios llegan a main

Como ingeniero QA, crearás ramas para nuevos suites de tests, actualizaciones de tests y reproducciones de bugs.

Conflictos de fusión: qué son y cómo corregirlos

Un conflicto de fusión ocurre cuando dos personas cambiaron la misma parte del mismo archivo y Git no puede combinarlos automáticamente.

<<<<<<< HEAD
await expect(page.getByText('Éxito')).toBeVisible();
=======
await expect(page.getByRole('alert')).toHaveText('Éxito');
>>>>>>> feature/actualizar-aserciones

La sección <<<<<<< HEAD es tu versión. La sección >>>>>>> feature/actualizar-aserciones es la versión entrante. Necesitas elegir una (o combinarlas manualmente), eliminar los marcadores de conflicto y confirmar.

La mayoría de los conflictos en repositorios de tests son fáciles de resolver. Ocurren más en archivos compartidos como playwright.config.ts o archivos de Page Object que varias personas tocan.

Git log: entender el historial

# Ver commits recientes
git log --oneline
# a3f2c1d Agregar tests de pago
# b7e9a04 Corregir locator de la página de login después de actualización de UI
# c2d1f8e Agregar test de creación de ítem con escenarios de validación

# Ver los cambios en un commit específico
git show a3f2c1d

# Ver quién modificó por última vez cada línea de un archivo
git blame tests/login.spec.ts

GitHub Actions: tu pipeline de CI

Una vez que tus tests están en GitHub, GitHub Actions puede ejecutarlos automáticamente en cada push. Un archivo 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

Este es el archivo que npm init playwright@latest ofrece crear para ti. Una vez que está en tu repositorio, GitHub ejecuta los tests en cada push y pull request. El artículo de CI/CD lo cubre en detalle.

Resumen de comandos

# Configuración
git config --global user.name "Nombre"
git config --global user.email "email"

# Uso diario
git status              # ver qué cambió
git pull                # obtener lo último del remoto
git add archivo.ts      # preparar un archivo
git add .               # preparar todos los archivos con cambios
git commit -m "mensaje" # guardar los cambios preparados
git push                # enviar al remoto

# Ramas
git checkout -b nombre-rama   # crear y cambiar
git checkout main              # cambiar a main
git branch                     # listar ramas
git merge nombre-rama          # fusionar rama en la actual

# Historial
git log --oneline              # commits recientes
git diff                       # cambios sin preparar
git show hash-commit           # cambios en un commit

FAQ

Los dos funcionan. VS Code tiene soporte integrado de Git (el panel de Control de código fuente) que cubre la mayoría de las operaciones diarias sin línea de comandos. GitHub Desktop es otra opción. Vale la pena aprender la línea de comandos porque la encontrarás en scripts de CI/CD y servidores remotos, pero empezar con una interfaz gráfica está bien.

Git es el software de control de versiones que corre localmente. GitHub es un sitio web que hospeda repositorios Git de forma remota. GitLab y Bitbucket son alternativas a GitHub. Git funciona sin GitHub; GitHub almacena y comparte tus repositorios Git.

Sé específico. "Agregar tests de login" es débil. "Agregar tests negativos de login: contraseña incorrecta, campos vacíos, inyección SQL" es útil. Un buen mensaje de commit responde: qué cambió y por qué (no cómo, el código muestra el cómo).

No entres en pánico. Si no hiciste push:

git reset HEAD~1  # deshacer el último commit, conservar los cambios
git checkout -b mi-rama  # crear una rama apropiada
git add .
git commit -m "mensaje"

Si hiciste push y tu equipo usa una rama main protegida, consulta con el tech lead. Nunca hagas force-push a main sin consenso del equipo.

Sí, si lo confirmaste antes:

git checkout HEAD -- ruta/al/archivo.ts

Esta es una de las funcionalidades más útiles de Git. Puedes recuperar cualquier cosa que haya sido confirmada alguna vez.