Qué es Git y por qué deberías usarlo

Qué es Git

Git es un sistema de control de versiones distribuido que registra los cambios en los archivos y permite a los equipos colaborar de forma eficiente en un mismo proyecto. Fue creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux y desde entonces se ha convertido en el estándar de facto del sector. Tanto si trabajas en solitario en un proyecto pequeño como en un equipo de cien desarrolladores, Git te permite registrar cada cambio, volver a versiones anteriores y trabajar en varias funcionalidades en paralelo sin conflictos.

A diferencia de sistemas más antiguos como SVN, Git es distribuido, lo que significa que cada desarrollador tiene una copia completa de todo el historial del proyecto en su ordenador. Esto permite trabajar sin conexión a internet, realizar operaciones más rápidas porque la mayoría de las cosas se hacen localmente y una mayor resistencia a la pérdida de datos, ya que cada clon es una copia de seguridad completa. Entender Git es hoy una habilidad básica para todo programador y desarrollador web.

Por qué usar Git

Seguimiento de cambios

Sin un sistema de control de versiones, los programadores recurren a copiar archivos manualmente. Para almacenar proyectos, considera un espacio de copias de seguridad con nombres como sitio-v2-final-copia-2.zip. Este enfoque es insostenible, porque enseguida resulta imposible saber qué versión contiene qué cambios. Git registra automáticamente cada cambio con información sobre quién lo hizo, cuándo y por qué. Puedes ver el historial completo del proyecto, comparar dos versiones cualesquiera y saber exactamente qué línea de código se modificó en cada momento.

Cada commit en Git es una instantánea del estado del proyecto en un momento concreto con un mensaje que describe qué cambió y por qué. Esto resulta valiosísimo cuando, meses después, necesitas entender por qué se hizo un cambio o encontrar el commit que introdujo un error. El comando git blame muestra quién modificó por última vez cada línea de código, lo que agiliza la localización de los responsables de una parte concreta del código.

Ramas y trabajo en paralelo

Las ramas de Git son una de sus funciones más potentes. Una rama es una línea de desarrollo independiente que te permite trabajar en una nueva funcionalidad sin afectar al código principal. Puedes crear una rama para cada corrección de errores o nueva funcionalidad, trabajar en ella el tiempo que haga falta y fusionarla con la rama principal solo cuando todo esté probado y listo. Si la funcionalidad resulta ser una mala idea, simplemente eliminas la rama sin ninguna consecuencia para el resto del proyecto.

En un equipo, cada programador puede trabajar en su propia rama sin preocuparse por sobrescribir el trabajo de otra persona. Git fusiona automáticamente los cambios de distintas ramas y, en la mayoría de los casos, lo hace sin intervención. Cuando surge un conflicto, Git marca claramente las partes problemáticas y pide al programador que lo resuelva manualmente. Esto es mucho mejor que el escenario alternativo, en el que dos programadores modifican el mismo archivo y uno sobrescribe el trabajo del otro sin previo aviso.

Copia de seguridad y recuperación

Todo repositorio Git alojado en un servidor remoto como GitHub sirve de copia de seguridad de todo el proyecto con el historial completo. Aunque tu disco duro falle, puedes clonar el repositorio en un ordenador nuevo en cuestión de segundos y continuar el trabajo exactamente donde lo dejaste. Git conserva todas las versiones de cada archivo que se haya confirmado alguna vez, lo que significa que puedes revertir cualquier archivo a cualquier estado anterior. Es un seguro de vida para cualquier proyecto.

Comandos básicos de Git

Inicialización y configuración

Empezar con Git requiere la instalación y una configuración básica. En la mayoría de las distribuciones de Linux, Git ya viene instalado o se instala con apt install git o dnf install git. En macOS viene con las Xcode Command Line Tools. Tras la instalación, configura el nombre y el correo electrónico que se usan en los commits con git config global user.name "Tu Nombre" y git config global user.email tu@email.com. Esta información se registra con cada commit.

Creas un nuevo repositorio con git init en el directorio del proyecto. Esto crea una carpeta oculta .git que contiene el historial completo y la configuración del repositorio. Como alternativa, puedes clonar un repositorio existente con git clone URL, que descarga el proyecto con todo su historial a tu ordenador. El archivo .gitignore define qué archivos debe ignorar Git, como el directorio node_modules, los archivos .env con secretos y los archivos binarios compilados.

Comandos del día a día

El comando git status muestra el estado actual del repositorio: qué archivos se han modificado, cuáles se han añadido al área de preparación (staging) y cuáles no se están siguiendo. Úsalo a menudo para tener una visión de lo que ocurre. Git add añade archivos al área de preparación, que es la antesala del commit. Puedes añadir archivos individuales con git add archivo.js o todos los archivos modificados con git add ., pero ten cuidado de no añadir archivos no deseados.

El comando git commit crea una instantánea del estado actual del área de preparación con un mensaje descriptivo. Un buen mensaje de commit es breve pero informativo, por ejemplo «Añadir validación del campo de correo en el formulario de contacto». La convención es escribir los mensajes en imperativo, como si dijeras lo que hace el commit. Git log muestra el historial de commits con los identificadores hash, los autores, las fechas y los mensajes. Usa git log oneline para una vista compacta o git log graph para una representación visual de las ramas.

Trabajar con ramas

Crear una nueva rama: git branch nombre-rama crea una rama pero no cambia a ella. Git checkout nombre-rama cambia a una rama existente. La combinación git checkout -b nombre-rama crea una nueva rama y cambia a ella de inmediato, que es el flujo de trabajo más habitual. Git moderno también ofrece el comando git switch, una alternativa más intuitiva a checkout al trabajar con ramas. Nombra las ramas de forma descriptiva, como feature/pedidos-online o fix/login-bug.

La fusión de ramas se hace con git merge nombre-rama mientras estás en la rama a la que quieres incorporar los cambios. El flujo típico es: cambiar a la rama principal y luego ejecutar el merge de tu rama de funcionalidad. Si no hay conflictos, Git fusiona el código automáticamente. Si los hay, Git marca las partes problemáticas en los archivos con marcadores especiales y eliges manualmente qué cambios conservar. Tras resolver los conflictos, confirmas el resultado con un commit.

GitHub y repositorios remotos

GitHub es la plataforma más popular para alojar repositorios Git, con más de 100 millones de usuarios. Además del almacenamiento de código, GitHub ofrece seguimiento de incidencias (issues), el flujo de pull requests, CI/CD con GitHub Actions, páginas wiki y mucho más. Entre las plataformas alternativas están GitLab, que ofrece autoalojamiento, y Bitbucket, que se integra bien con las herramientas de Atlassian como Jira.

El comando git remote add origin URL conecta el repositorio local con el remoto en GitHub. Git push envía tus commits al servidor remoto, donde otros miembros del equipo pueden verlos y descargarlos. Git pull descarga los últimos cambios del remoto y los fusiona con tu código local. Git fetch descarga los cambios pero no los fusiona automáticamente, lo que te da la oportunidad de revisarlos antes de fusionarlos.

Flujo de trabajo con Pull Requests

Un pull request o PR es un mecanismo para revisar el código antes de fusionarlo con la rama principal. El programador crea una rama, confirma los cambios, los sube a GitHub y abre un PR con una descripción de los cambios. Otros miembros del equipo revisan el código y dejan comentarios y sugerencias. Solo tras la aprobación de uno o más revisores se fusiona el PR con la rama principal. Este flujo garantiza la calidad del código y el intercambio de conocimiento en el equipo, porque cada programador ve lo que hacen los demás.

Un buen PR tiene un mensaje claro que describe qué cambió y por qué, un tamaño razonable —ya que revisar un PR con miles de líneas de código es imposible— y comprobaciones automáticas como tests y linting que se ejecutan a través de CI/CD. GitHub Actions puede ejecutar tests automáticamente en cada push y mostrar el resultado en el PR, evitando la fusión de código que rompe los tests.

Git en el flujo de despliegue

Git es la base del despliegue moderno, especialmente en servidores VPS. El enfoque más sencillo es el despliegue manual, en el que se ejecuta git pull en el servidor para descargar los últimos cambios. Esto basta para webs pequeñas, pero no escala bien y es propenso a errores humanos. Un mejor enfoque es el despliegue automatizado, en el que un push a una rama concreta como main activa automáticamente el despliegue a través de una pipeline de CI/CD.

Un flujo automatizado típico es así: el programador sube el código a GitHub, GitHub Actions ejecuta los tests y la compilación (build), si todo pasa el código se despliega automáticamente en el servidor de staging para pruebas y, tras la aprobación, se despliega en producción. Este enfoque elimina la posibilidad de olvidar ejecutar los tests o de desplegar la versión equivocada. En BeoHosting admitimos el despliegue con Git en todos los planes de hosting, con automatización mediante webhooks.

Estrategias de Git para equipos

Git Flow es una estrategia de ramificación popular que define funciones para distintas ramas: main para el código de producción, develop para el desarrollo, ramas feature para nuevas funcionalidades, ramas release para preparar versiones y ramas hotfix para correcciones urgentes en producción. Esta estrategia es exhaustiva, pero puede resultar demasiado compleja para equipos pequeños. El trunk-based development es una alternativa más sencilla en la que todos los programadores confirman directamente en la rama principal con ramas de funcionalidad de corta duración, de uno o dos días.

Independientemente de la estrategia, varias reglas son universales: nunca confirmes directamente en la rama principal, usa siempre un PR para la revisión, escribe mensajes de commit descriptivos, mantén los commits pequeños y centrados en un solo cambio, y nunca confirmes secretos como contraseñas o claves de API. Si confirmas un secreto por accidente, cámbialo de inmediato, porque incluso después de eliminarlo del historial es posible que alguien ya lo haya descargado.

Conclusión

Git es una herramienta imprescindible para cualquiera que trabaje con código, ya seas un desarrollador en solitario o formes parte de un gran equipo. Invertir en aprender Git se amortiza con creces gracias a una mejor organización, la seguridad del código y un trabajo en equipo más eficiente. Empieza con los comandos básicos, usa GitHub para alojar tus repositorios e introduce poco a poco flujos de trabajo más avanzados. En BeoHosting admitimos el despliegue con Git en todos los planes de hosting, lo que te permite desplegar de forma rápida y fiable directamente desde tu repositorio.