Git y GitHub

Del historial en tu carpeta al remoto en la nube: instalar, Git GUI, commits, ramas, pull requests y cómo salir de un conflicto sin romper el proyecto.

Desde cero Git GUI Terminal Práctica

Descargar .tex Descargar .md

Ramas: trabajar sin romper lo estable

En un repositorio, la línea que consideras oficial suele llamarse main (en proyectos antiguos a veces sigue siendo master). Ahí debería vivir la versión que funciona y, si despliegas, la que pondrías en producción. Cuando vas a tocar algo grande —un login, un rediseño, un experimento— no conviene escribir esos cambios directamente encima de main: si algo se rompe a medias, no tienes un camino limpio al que volver.

Una rama es un camino paralelo en el historial. Creas la rama, haces commits allí y, cuando la pieza está lista, la fusionas (merge) con main. Hasta ese momento, los commits de la rama no alteran la línea estable.

Dos personas, dos ramas. Cada una avanza sin tocar main hasta el merge (o el Pull Request). Así el trabajo estable no se mezcla con experimentos a medias.

Por qué las ramas evitan que os piséis

Si varios editáis directamente en main y hacéis push, el primero que sube gana; el segundo recibe un rechazo o un conflicto, y a menudo encima de código a medias. Con una rama por tarea ocurre otra cosa: cada uno tiene su historial paralelo, sube su rama al remoto y propone fusionarla cuando está lista. Mientras tanto, main sigue siendo la base común en la que todos confiáis.

Git no sustituye al acuerdo del equipo («yo toco el login, tú la API»), pero sí aísla los cambios. Si chocáis en las mismas líneas al fusionar, el conflicto aparece en un momento controlado —al hacer merge o al actualizar la rama— y se resuelve en Conflictos, no a ciegas en mitad del día.

Flujo de trabajo en equipo (el más habitual)

Este es el ciclo que usan la mayoría de equipos pequeños y medianos. Encaja con GitHub y con casi cualquier remoto:

Actualiza main local. Al empezar (o al retomar el proyecto): git switch main y git pull. Así partes de lo último que el equipo ya fusionó.
Crea tu rama de trabajo. Un nombre que diga la tarea: feature-login, fix-iva-ticket, docs-readme. Una tarea = una rama. No mezcles el rediseño del menú con el arreglo del IVA en la misma rama.
Trabaja y haz commits ahí. Commits pequeños cuando una pieza ya funciona. No hace falta (ni conviene) empujar a main todavía.
Sube la rama al remoto. git push -u origin nombre-de-tu-rama. Así hay copia en GitHub, puedes abrir un Pull Request y no dependes solo de tu disco.
Abre un Pull Request (PR). En GitHub: Compare & pull request hacia main. El compañero ve el diff, comenta y, si está bien, aprueba el merge. Hasta entonces, main no cambia.
Tras el merge, limpia. Vuelve a main, haz pull, y borra la rama local (y en remoto si ya no hace falta). La siguiente tarea empieza otra vez desde el paso 1.

1 pull main Base actualizada

2 rama propia feature-…

3 commits En tu rama

4 push rama Copia en remoto

5 Pull Request Revisión → merge

6 pull main Todos al día

Ritmo diario para no solaparos

Al empezar

Pasa a main, haz pull y, si sigues en una rama antigua, actualízala con lo nuevo de main (git merge main estando en tu rama, o git rebase main si el equipo ya usa rebase). Así no construyes encima de un main viejo.

Antes de tocar un archivo

Si el login, el CSS global o el schema.sql son «territorio compartido», avisa. Dos ramas pueden editar el mismo fichero; Git lo permite, pero el merge será más doloroso. Dividid por zonas cuando podáis.

Al cerrar una pieza

Commit + push de tu rama. No hace falta esperar a que esté «perfecto el proyecto entero»: cuanto antes esté la rama en el remoto, antes alguien puede revisar el PR.

Lo que no conviene

Commitear en main «porque voy solo un rato». Hacer push --force a main. Mezclar tres tareas en una sola rama. Dejar una rama abierta dos semanas sin actualizarla con main.

Comandos del flujo (terminal)

Ejemplo completo: partes de main al día, abres rama, trabajas, subes y más adelante actualizas tu rama con lo que ya entró en main:

git switch main
git pull
git switch -c feature-login
# …editas, git add, git commit…
git push -u origin feature-login
# …otro ya fusionó algo a main; actualizas tu rama…
git switch main
git pull
git switch feature-login
git merge main
# resuelves conflictos si salen; luego push otra vez
git push

El Pull Request se abre en la web de GitHub (o GitLab). Cuando lo fusionen, en tu máquina:

git switch main
git pull
git branch -d feature-login

En Git GUI

Menú Branch → Create: pon el nombre de la tarea y marca Checkout after create para quedarte ya dentro de esa rama.
Trabaja como siempre: Rescan → stage → Commit, pero estando en tu rama. Compruébalo en el título de la ventana (debe verse el nombre de la feature, no solo main).
Haz Push de esa rama. No empujes a main salvo que estés actualizando la línea estable a propósito.
Para traer otra rama a la actual: Merge → Local Merge. Para volver a main: Branch → Checkout.

El detalle de conectar el remoto, el token y el botón de Pull Request está en GitHub. Si al fusionar o al actualizar la rama aparecen marcadores <<<, sigue Conflictos.

Regla práctica: main se toca poco y con revisión; el trabajo del día vive en ramas cortas, con nombre claro, que se fusionan pronto. Así nadie pisa el historial estable y cada uno puede avanzar sin esperar a que el otro «termine el archivo».