La gestión de proyectos web, especialmente aquellos basados en generadores de sitios estáticos como Hexo, a menudo requiere una estrategia de versionado que permita la sincronización de archivos fuente. Una solución común es utilizar ramas de Git para separar el código fuente del sitio de los archivos generados y desplegados. Este enfoque permite mantener el repositorio principal del sitio web (por ejemplo, en GitHub Pages) con los archivos publicados, mientras que los archivos fuente del blog residen en una rama distinta dentro del mismo repositorio.

Preparación Inicial del Repositorio

Para comenzar, es necesario clonar el repositorio remoto en su máquina local. Si ya tiene un repositorio local existente, asegúrese de que esté sincronizado con la versión remota. Si es un repositorio nuevo, use:

git clone <URL_DEL_REPOSITORIO>

Si el repositorio ya existe localmente, simplemente asegúrese de tener la última versión del origen:

git pull origin main

Esto asegura que su copia local esté actualizada con el contenido del servidor.

Creación y Gestión de Ramas Locales

Una vez configurado el repositorio, el siguiente paso es crear una rama para almacenar el código fuente de su proyecto (por ejemplo, los archivos de Hexo). Puede crear una nueva rama y cambiar a ella inmediatamente con un solo comando:

git checkout -b fuente-proyecto

Este comando crea una rama llamada fuente-proyecto y automáticamente la activa. Alternativamente, puede realizar estos pasos por separado:

# 1. Crear una nueva rama
git branch fuente-proyecto

# 2. Cambiar a la rama recién creada
git checkout fuente-proyecto

Una vez en la nueva rama, puede añadir, modificar y confirmar sus archivos de código fuente.

Visualización de Ramas

Para ver las ramas disponibles en su repositorio local, utilice:

git branch

La rama actualmente activa se marcará con un asterisco. Para ver tanto las ramas locales como las remotas:

git branch -r

Eliminación de Ramas

Cuando una rama ya no es necesaria, puede eliminarla. Asegúrese de no estar en la rama que desea eliminar.

# Eliminar una rama local (solo si ya ha sido fusionada o está seguro de que no la necesita)
git branch -d rama-antigua

Cambio entre Ramas

Para alternar entre diferentes ramas:

git checkout master

Este comando le devolverá a la rama master (o main, dependiendo de la convención de su repositorio).

Sincronización de Ramas con el Repositorio Remoto

Una vez que haya realizado cambios en su rama local y los haya confirmado (git commit), puede subirlos al repositorio remoto:

# Subir la rama local al repositorio remoto con el mismo nombre
git push origin nombre-de-mi-rama-local

También es posible subir una rama local asignándole un nombre diferente en el repositorio remoto, o empujar una rama local a una rama remota específica:

# Subir la rama local 'mi-rama-dev' como 'dev-remota' en el origen
git push origin mi-rama-dev:dev-remota

# Ejemplo: Subir la rama local 'fuente-hexo' como 'fuente-blog' en el repositorio remoto
git push origin fuente-hexo:fuente-blog

Manejo de Submódulos y el Estado "Dirty"

Al trabajar con proyectos que incluyen submódulos Git (como los temas en un sitio Hexo), es común encontrarse con un estado de "contenido modificado" en el submódulo que impide un git commit limpio en el repositorio padre. Esto se manifiesta con mensajes similares a:

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)

	modified:   themes/next (modified content)
no changes added to commit (use "git add" and/or "git commit -a")

Este mensaje indica que el repositorio padre detecta cambios en su submódulo (themes/next en este ejemplo), considerándolo en un estado "sucio" (dirty). Esto ocurre inccluso si no se tiene la intención de registrar esos cambios del submódulo en el repositorio padre.

Una solución común para situaciones donde no se desea que el repositorio padre rastree los cambios internos del submódulo (por ejemplo, si los temas de Hexo se actualizan independientemente o no se quieren versionar sus modificaciones dentro del repositorio principal) es configurar Git para ignorar el estado "dirty" de un submódulo específico. Esto se puede lograr con:

git config submodule.themes/next.ignore dirty

Donde themes/next es la ruta al submódulo. Esta configuración le indica a Git que ignore los cambios de estado dentro de ese submódulo específico, permitiendo realizar commits en el repositorio padre sin ser bloqueado por el estado interno del submódulo.