Main y Master Branch en Git: qué es y por qué se necesita la rama principal

Qué es Main / Master Branch en Git

Main Branch (o Master — según la configuración del repositorio) es la rama por defecto que se crea al inicializar cualquier repositorio Git. Es la rama principal del proyecto y contiene código listo para implementarse en producción.

A diferencia de develop, donde el trabajo diario con nuevas funciones está en pleno apogeo, main es el escaparate del proyecto. Cada versión del código en main ha pasado por un ciclo completo: desarrollo en una rama feature, integración en develop, preparación del lanzamiento en una rama release y pruebas finales. Solo después de eso los cambios llegan a main.

Principio clave: main siempre debe ser estable. Si se encuentra un error en main, significa que se necesita un hotfix urgente fuera de turno. Por lo tanto, en proyectos profesionales, main está protegida contra cambios accidentales mediante reglas de protección de rama.

Según Git Book, main no es una rama especial con propiedades únicas, sino una referencia normal a un commit que por convención se considera principal. Git no hace distinción entre main y cualquier otra rama a nivel del sistema.

Transición de master a main

Históricamente, la rama por defecto en Git se llamaba master. En junio de 2020, el movimiento Black Lives Matter llamó la atención sobre los términos master y slave en la industria TI. GitHub anunció la transición al término main para la rama por defecto.

Desde octubre de 2020, todos los repositorios nuevos en GitHub se crean con la rama main. GitLab y Bitbucket también implementaron soporte para main como nombre por defecto. Git 2.28 (julio de 2020) agregó la opción init.defaultBranch para configurar el nombre de la rama por defecto.

Técnicamente, renombrar una rama existente de master a main es una operación simple. El principal desafío es actualizar todas las referencias en las configuraciones de CI/CD, documentación y repositorios locales de los desarrolladores.

Para renombrar una rama en un repositorio existente, ejecute:

# Renombrar localmente master a main
git branch -m master main

# Actualizar el repositorio remoto
git push -u origin main

# Eliminar el antiguo master en el servidor
git push origin --delete master

# Actualizar HEAD en el servidor
# (a través de la interfaz web de GitHub: Settings → Branches → Default branch)

Rol de main en Git Flow y GitHub Flow

Git Flow y GitHub Flow definen el rol de la rama main de manera diferente. La elección del modelo depende del tamaño del equipo, la frecuencia de lanzamientos y los requisitos de estabilidad del código.

Para el desarrollo móvil, Git Flow es el estándar, ya que publicar una aplicación en App Store y Google Play tiene ciclos de lanzamiento fijos. GitHub Flow es más adecuado para proyectos web que se pueden implementar varias veces al día.

GitHub Flow — enfoque simplificado

En GitHub Flow, no hay rama develop. Todas las ramas feature se crean directamente desde main y, al finalizar, se fusionan mediante un Pull Request. Cada fusión en main activa automáticamente el despliegue a producción. Este modelo requiere un alto nivel de automatización de pruebas y disciplina del equipo.

En GitHub Flow, no hay rama develop. Todas las ramas feature se crean directamente desde main y, al finalizar, se fusionan mediante un Pull Request. Cada fusión en main activa automáticamente el despliegue a producción. Este modelo requiere un alto nivel de automatización de pruebas y disciplina del equipo.

Protección de la rama main

Branch protection para main es una configuración obligatoria en cualquier proyecto comercial. Sin ella, un push accidental podría enviar código incompleto a producción o romper una aplicación en funcionamiento para todos los usuarios.

• Require pull request — el push directo a main está prohibido. Todos los cambios mediante PR con revisión.
• Require approvals — mínimo 2 aprobaciones para fusionar en main (por si un revisor pasa algo por alto).
• Require status checks — todas las comprobaciones de CI/CD deben ser exitosas antes de fusionar.
• Require up-to-date — el PR debe basarse en el último commit de main.
• Include administrators — la protección se aplica incluso a los propietarios del repositorio.
• Require signed commits — todos los commits en main deben estar firmados con una clave GPG.

Configurar las seis reglas es el estándar para proyectos móviles con una audiencia de 10 000+ usuarios. Para proyectos pequeños, las tres primeras reglas son suficientes.

Comparación de niveles de protección para diferentes tipos de proyectos

El nivel de protección de main depende de la escala del proyecto. Una startup puede arreglárselas con protección mínima, mientras que una aplicación empresarial requiere restricciones máximas.

Lanzamientos y etiquetas en main

Tagging es la práctica de crear referencias con nombre a commits específicos en main. Cada etiqueta corresponde a una versión de la aplicación publicada en producción. Esto permite cambiar rápidamente a cualquier versión anterior para depuración o parches.

El estándar de nomenclatura de etiquetas en el desarrollo móvil es SemVer (Versionado Semántico): v1.2.3, donde el primer número es la versión mayor (cambios importantes), el segundo es la versión menor (nuevas funciones) y el tercero es el parche (correcciones).

Se crea una etiqueta después de fusionar la rama release en main. Luego, este commit se compila en CI/CD, se firma y se envía a la tienda de aplicaciones. Si se encuentra un error en la etiqueta, se crea una rama hotfix desde esa etiqueta.

# Crear etiqueta de lanzamiento anotada
git tag -a v2.4.1 -m "Release version 2.4.1"

# Enviar etiqueta al servidor
git push origin v2.4.1

# Ver todas las etiquetas en el repositorio
git tag -l "v2.*"

# Crear rama hotfix desde una etiqueta específica
git checkout -b hotfix/crash-fix v2.4.1

Jerarquía de ramas en Git Flow

Comprender la jerarquía de ramas en Git Flow es la base para organizar adecuadamente el desarrollo colaborativo. Cada tipo de rama tiene su propia fuente, propósito y reglas de fusión.

• Main (Nivel 1) — la rama raíz, contiene solo versiones de lanzamiento. Se crea al inicializar un repositorio.
• Develop (Nivel 2) — se crea desde main al inicio del proyecto. Contiene código de integración de todas las funciones.
• Feature (Nivel 3) — se crea desde develop. Desarrollo aislado de funciones individuales.
• Release (Nivel 2) — se crea desde develop. Preparación de un lanzamiento específico para su publicación.
• Hotfix (Nivel 2) — se crea desde main. Correcciones urgentes de errores críticos de producción.

Regla importante: feature nunca se fusiona directamente en main. feature → develop → release → main es la cadena de fusión correcta. Violar esta regla anula el propósito de todo el modelo Git Flow.

Ejemplos de comandos para trabajar con main

Considere un escenario: el equipo ha completado la preparación del lanzamiento v2.5.0. La rama release está revisada y lista para fusionarse en main. Después de la fusión, se crea una etiqueta y se publica el lanzamiento.

# Cambiar a main y actualizar
git checkout main
git pull origin main

# Fusionar la rama release verificada
git merge --no-ff release/2.5.0

# Crear etiqueta de lanzamiento
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Enviar main y la etiqueta al servidor
git push origin main --tags

La bandera --no-ff (sin avance rápido) garantiza la creación de un commit de fusión, incluso si la fusión podría haberse realizado simplemente moviendo el puntero. Esto preserva la información de que los cambios provinieron de una rama release, lo que facilita el análisis del historial.

Trabajar con hotfix a través de main

Si se descubre un error crítico en producción, el proceso difiere de un lanzamiento normal. Se crea un hotfix desde main y, después de la corrección, se fusiona tanto en main como en develop.

Si se descubre un error crítico en producción, el proceso difiere de un lanzamiento normal. Se crea un hotfix desde main y, después de la corrección, se fusiona tanto en main como en develop.

# Crear rama hotfix desde main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Corregir y hacer commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Fusionar hotfix de vuelta a main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Fusionar hotfix también en develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Eliminar rama hotfix
git branch -d hotfix/2.5.1-crash-fix