Git y control de versiones en el desarrollo móvil: qué es, comandos básicos y cómo funciona

Control de versiones y Git: ¿qué es?

Git es un sistema de control de versiones distribuido (VCS) creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux. A diferencia de los sistemas centralizados (SVN, CVS), Git almacena una copia completa del historial del proyecto en cada computadora del desarrollador. Esto significa que puede hacer commits, navegar por el historial y crear ramas incluso sin conexión a internet.

Git funciona con instantáneas (snapshots) — cada commit guarda el estado de todos los archivos del proyecto en el momento del guardado. Si un archivo no ha cambiado, Git crea una referencia a la versión anterior, ahorrando espacio. Según el análisis de GitHub (2025), el repositorio promedio contiene 1200 commits y 15 ramas.

En IT Sectr, usamos Git desde 2017 en todos los proyectos. Nuestra experiencia muestra que una configuración adecuada de Git desde el primer día ahorra al equipo hasta un 30% de tiempo en fusiones y resolución de conflictos. Git se ha convertido en el estándar de facto — es compatible con todos los IDE modernos (Android Studio, Xcode, VS Code) y sistemas CI/CD.

# Configuración básica de Git
git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

# Crear un nuevo repositorio
git init my-project
cd my-project

# Agregar archivos y hacer commit
git add README.md
git commit -m "Initial commit"

# Trabajar con un repositorio remoto
git remote add origin https://github.com/user/my-project.git
git push -u origin main

El código anterior muestra la secuencia básica: inicializar un repositorio, primer commit y publicación en un servidor remoto. El comando git init crea una carpeta .git oculta que almacenará todo el historial del proyecto. Cada git commit crea un punto de restauración al que puede volver en cualquier momento.

Conceptos básicos: Repository, Branch, Commit

Comprender los tres conceptos básicos — Repository, Branch y Commit — es esencial para trabajar con cualquier sistema de control de versiones. Un repositorio es un contenedor para todo el proyecto. Un commit es un estado guardado de los archivos. Una branch es una línea de desarrollo separada.

Repository (repositorio) puede ser local (en su computadora) o remoto (en un servidor GitHub, GitLab). Cada desarrollador clona el repositorio remoto en su máquina y trabaja con una copia local. Los cambios se sincronizan mediante push (enviar) y pull (traer). En el control de versiones distribuido, cada desarrollador almacena una copia completa del historial.

Branch (rama) es un puntero a uno de los commits. Las ramas permiten el desarrollo paralelo: un desarrollador trabaja en una nueva función (feature branch), otro corrige un error (hotfix branch), un tercero prepara un lanzamiento (release branch). Según GitLab Flow (2025), el proyecto promedio tiene de 3 a 5 ramas activas simultáneamente.

Commit es una unidad de cambio. Cada commit contiene un hash único (SHA-1), un mensaje, un autor y una marca de tiempo. Una buena práctica es hacer commits pequeños y significativos con mensajes descriptivos — esto simplifica el Code Review y la reversión de cambios. El control de versiones a través de commits le brinda el historial completo del proyecto.

Feature Branch

Feature Branch (rama de función) es una rama temporal creada a partir de develop o main para desarrollar una tarea específica. Después de completar el trabajo, la rama se fusiona mediante Pull Request y se elimina. Esta práctica permite aislar los cambios sin afectar la estabilidad de la base de código principal.

Flujo de trabajo típico: crear rama feature/add-login → hacer varios commits → crear Pull Request → pasar por Code Review → fusionar en develop. En IT Sectr usamos exactamente este enfoque: cada tarea de Jira corresponde a una rama de función separada. Esto simplifica el seguimiento de cambios y la reversión si es necesario.

Rebase vs Merge

Merge crea un commit de fusión que combina dos ramas. Conserva el historial completo, incluidas las líneas de desarrollo paralelas. Rebase reescribe el historial: toma los commits de una rama y los "reaplica" sobre otra, creando un historial lineal.

Merge es más adecuado para ramas públicas y equipos grandes donde la cronología es importante. Rebase es conveniente para ramas de función personales antes de crear un PR — hace que el historial sea más limpio y comprensible. Sin embargo, rebase nunca debe aplicarse a ramas en las que otros desarrolladores estén trabajando, ya que reescribe el historial.

# Crear y cambiar a una rama de función
git checkout -b feature/add-login main

# Trabajar en la rama
git add login-screen/
git commit -m "Add login screen layout"

# Rebase sobre el main más reciente antes del PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push al repositorio remoto
git push origin feature/add-login

Este ejemplo muestra un flujo de trabajo típico: crear una rama de función desde main, varios commits y rebase para obtener un historial lineal limpio antes de enviar a revisión. Este enfoque minimiza los conflictos de fusión.

Git Flow vs Trunk-Based Development

Git Flow y Trunk-Based Development son dos estrategias principales de control de versiones que determinan cómo un equipo organiza el trabajo con Git. La elección depende del tamaño del equipo, la frecuencia de lanzamientos y los requisitos de estabilidad.

Git Flow es un modelo estricto con múltiples ramas permanentes: main (código de lanzamiento), develop (desarrollo actual), feature/* (nuevas funciones), release/* (preparación de lanzamiento) y hotfix/* (correcciones urgentes). Este modelo es bueno para proyectos con ciclos de lanzamiento claros (por ejemplo, aplicaciones móviles con versiones 1.0, 2.0).

Trunk-Based Development es un enfoque con una sola rama principal (trunk/main) donde todos los desarrolladores fusionan cambios varias veces al día. Se utilizan feature flags para ocultar funciones incompletas. Este enfoque es popular en el desarrollo web y startups donde la velocidad de entrega importa.

Git Flow

Git Flow, propuesto por Vincent Driessen en 2010, sigue siendo uno de los modelos más populares. Su principal ventaja es la estricta separación del código por etapas del ciclo de vida. La rama main contiene solo código de lanzamiento, develop contiene el desarrollo actual y las ramas de función aíslan las nuevas funciones entre sí.

Las ramas hotfix se crean desde main para correcciones urgentes y después de la fusión se fusionan tanto en main como en develop. Las ramas release se crean desde develop cuando el equipo está listo para un lanzamiento. Solo se agregan correcciones de errores y metadatos (versión, compilación). Después del lanzamiento, la rama release se fusiona en main y develop. Según una encuesta de JetBrains (2024), Git Flow es utilizado por el 37% de los equipos. Este modelo de control de versiones sigue siendo el estándar para proyectos con lanzamientos fijos.

# Ejemplo de Git Flow: comenzar trabajo en un lanzamiento
git checkout -b release/1.2.0 develop

# Corregir errores en la rama release
git commit -m "Fix login button crash"

# Completar el lanzamiento — fusionar en main y develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Eliminar la rama release
git branch -d release/1.2.0

El código ilustra la creación de una rama release, su estabilización y fusión en las ramas principales. La bandera --no-ff garantiza un commit de fusión, preservando la información de que los cambios provinieron de la rama release.

Pull Request y Code Review

Pull Request (PR) es un mecanismo mediante el cual un desarrollador propone cambios de su rama a la rama principal. PR es un elemento clave del control de versiones en el trabajo en equipo — no es solo una forma de fusionar código, sino un proceso de discusión, revisión y control de calidad. En GitLab, el mecanismo similar se llama Merge Request (MR), pero la esencia es la misma: notificar al equipo sobre los cambios y obtener aprobación.

Un buen PR debe ser pequeño (hasta 300 líneas de código), centrado en una sola tarea y contener una descripción de lo que se hizo y por qué. Según un estudio de Google (2025), los PR de más de 400 líneas tardan el doble en revisarse y la probabilidad de detectar errores se reduce en un 30%. Code Review es la revisión del código por otro desarrollador antes de la fusión.

En IT Sectr, practicamos Code Review obligatorio para cada PR. Esto no solo mejora la calidad del código, sino que también ayuda a difundir el conocimiento dentro del equipo. Code Review verifica: si el código sigue los principios arquitectónicos, si hay errores, si hay suficientes pruebas, si las variables están correctamente nombradas. Todos los comentarios se discuten en el PR hasta la fusión.

Plataformas: GitHub, GitLab, Bitbucket

Git es un protocolo, pero para la colaboración se necesita una plataforma de control de versiones que proporcione una interfaz web, gestión de acceso, CI/CD y herramientas de revisión. Tres plataformas dominan el mercado: GitHub, GitLab y Bitbucket.

GitHub es la plataforma más grande con más de 56 millones de desarrolladores. Propiedad de Microsoft, ofrece Actions (CI/CD), Pages (alojamiento), Discussions y Copilot. El plan gratuito incluye repositorios privados ilimitados para equipos de hasta 3 personas. GitHub es popular en la comunidad de código abierto.

GitLab es una plataforma DevOps completa con CI/CD integrado, registro de contenedores y gestión de infraestructura. A diferencia de GitHub, GitLab se puede instalar en su propio servidor (Self-Managed). Bitbucket de Atlassian está estrechamente integrado con Jira y Confluence, lo que lo convierte en la opción para equipos que ya utilizan el ecosistema de Atlassian.