Sin embargo, también puede pasar que una rama se cree desde una base incorrecta. Por ejemplo, en lugar de crear una nueva rama desde main, se crea desde otra rama de desarrollo que todavía no está lista para integrarse. Cuando esto ocurre, el Pull Request puede mostrar muchos commits adicionales que no pertenecen realmente al cambio que queremos subir.

El problema

Supongamos que tenemos una rama principal:

main

También existe una rama de desarrollo para una integración grande:

feature/integracion-api

Después se crea una nueva rama para una funcionalidad más pequeña, por ejemplo el registro del costo de envío:

feature/integracion-envios

El detalle es que esta última rama fue creada accidentalmente desde feature/integracion-api y no desde main. Entonces, al intentar crear un Pull Request hacia main, GitHub muestra que se van a aplicar muchos commits adicionales.

En ese punto la señal de alerta es clara: si la funcionalidad era pequeña, pero el Pull Request muestra demasiados commits o archivos que no corresponden, no conviene hacer el merge todavía.

Por qué no era buena idea hacer el merge directo

Si se hacía el merge directo de feature/integracion-envios hacia main, también se podían integrar cambios incompletos de la rama feature/integracion-api. Esto habría mezclado funcionalidades distintas y pudo provocar errores en producción o en el ambiente de pruebas.

El objetivo era integrar únicamente los commits relacionados con el registro del costo de envío, sin arrastrar el trabajo de otra rama.

La solución: crear una rama limpia desde main

La solución fue crear una nueva rama partiendo correctamente desde main y después aplicar únicamente los commits necesarios usando git cherry-pick.

El comando git cherry-pick permite tomar uno o varios commits específicos de otra rama y aplicarlos sobre la rama actual. Esto resulta útil cuando queremos rescatar cambios puntuales sin mezclar todo el historial de la rama original.

1. Actualizar la información del repositorio

Primero se actualiza la información del repositorio remoto:

git fetch origin

Este comando descarga las referencias más recientes de las ramas remotas, sin modificar directamente el código de la rama actual.

2. Cambiar a main y actualizarla

Después se cambia a la rama principal y se actualiza con los últimos cambios disponibles:

git checkout main
git pull origin main

Esto asegura que la nueva rama limpia se cree desde la versión más reciente de main.

3. Crear una nueva rama limpia

Con main actualizada, se crea una nueva rama limpia para la funcionalidad:

git checkout -b feature/integracion-envios-clean

Esta nueva rama ya no tendrá como base la rama de integración grande, sino directamente main.

4. Identificar los commits correctos

El siguiente paso es identificar los commits que realmente corresponden a la funcionalidad de envíos.

git log --oneline origin/feature/integracion-api..origin/feature/integracion-envios

Este comando ayuda a visualizar los commits que existen en la rama de envíos, pero que no forman parte de la rama base desde la que fue creada.

El resultado puede ser algo como:

abc1234 Agrega campo de costo de envío al pedido
def5678 Ajusta cálculo total incluyendo envío

En este ejemplo, esos dos commits serían los únicos que realmente se necesitan aplicar en la rama limpia.

5. Aplicar los commits con cherry-pick

Una vez identificados los commits correctos, se aplican sobre la rama limpia:

git cherry-pick abc1234 def5678

Con esto, Git toma los cambios introducidos por esos commits y los aplica sobre la rama actual, generando nuevos commits con esos mismos cambios.

Si durante el proceso aparecen conflictos, se deben resolver manualmente, agregar los archivos corregidos y continuar el cherry-pick:

git add .
git cherry-pick --continue

Si fuera necesario cancelar el proceso, se puede usar:

git cherry-pick --abort

6. Revisar los cambios antes de subir la rama

Antes de subir la nueva rama, se revisa el estado del repositorio:

git status

También es recomendable revisar qué archivos quedaron modificados:

git diff --name-only main...feature/integracion-envios-clean

La idea es confirmar que la rama limpia solo contiene archivos relacionados con la funcionalidad que se quiere integrar.

7. Subir la rama limpia al repositorio remoto

Una vez revisado todo, se sube la nueva rama a GitHub:

git push -u origin feature/integracion-envios-clean

Después de esto, ya es posible crear un nuevo Pull Request desde la rama limpia hacia main.

8. Crear el Pull Request correcto

En GitHub, el nuevo Pull Request debe quedar configurado de esta forma:

base: main
compare: feature/integracion-envios-clean

Ahora el Pull Request mostrará únicamente los commits necesarios y los archivos relacionados con el registro del costo de envío.

Esto permite hacer una revisión más clara, evitar mezclar funcionalidades y mantener la rama main limpia.

Flujo completo de comandos

El flujo completo quedaría de la siguiente manera:

git fetch origin

git checkout main
git pull origin main

git checkout -b feature/integracion-envios-clean

git log --oneline origin/feature/integracion-api..origin/feature/integracion-envios

git cherry-pick abc1234 def5678

git status

git diff --name-only main...feature/integracion-envios-clean

git push -u origin feature/integracion-envios-clean

Buenas prácticas para evitar este problema

Antes de empezar una nueva funcionalidad, es recomendable seguir este flujo:

git checkout main
git pull origin main
git checkout -b feature/nueva-funcionalidad

También conviene revisar la rama actual antes de crear una nueva:

git branch --show-current

Con este pequeño hábito se evitan muchos problemas al momento de crear Pull Requests.

Conclusión

Cuando una rama se crea desde la base incorrecta, no siempre es necesario rehacer todo el trabajo. Si los cambios están organizados en commits claros, podemos crear una rama limpia desde main y aplicar únicamente los commits necesarios con git cherry-pick.

En este caso, la solución fue evitar el merge directo, crear una nueva rama limpia, aplicar los commits correctos y generar un Pull Request más claro y seguro. Esto permitió integrar la funcionalidad sin arrastrar cambios de otra rama que todavía no estaba lista.

Este tipo de situaciones son comunes en proyectos reales, y aprender a resolverlas correctamente ayuda a mantener un historial limpio, reducir errores y mejorar el flujo de trabajo en equipo.

En este artículo veremos cómo migrar la autenticación de un proyecto desde HTTPS con token hacia SSH, cómo validar que la conexión funcione correctamente y qué hacer cuando Git no permite cambiar de rama porque existen archivos locales modificados, como puede pasar con archivos de configuración en Laravel.

El problema: el token de acceso ya venció

Supongamos que tenemos un proyecto Laravel en un servidor de pruebas o demo. Al intentar ejecutar comandos como git fetch, git pull o git checkout, GitHub responde con un error de autenticación porque el token que se usaba anteriormente ya venció.

En muchos casos, aunque ya hayamos creado una llave SSH en el servidor, Git seguirá usando el token anterior si el repositorio todavía tiene configurada una URL remota con HTTPS.

Es decir, crear una llave SSH no cambia automáticamente la forma en que Git se conecta al repositorio. También debemos actualizar la URL remota del proyecto.

1. Revisar la URL remota actual

Primero debemos entrar a la carpeta del proyecto y revisar qué URL remota está usando Git.

cd /ruta/general/del/proyecto

git remote -v

Si la respuesta muestra una URL similar a esta:

origin  https://github.com/usuario/repositorio.git (fetch)
origin  https://github.com/usuario/repositorio.git (push)

significa que el proyecto todavía está usando HTTPS.

En algunos casos, incluso puede aparecer un token dentro de la URL, algo parecido a esto:

origin  https://TOKEN@github.com/usuario/repositorio.git

Ese es el escenario que debemos corregir.

2. Cambiar la URL remota de HTTPS a SSH

Para que Git use la llave SSH, debemos cambiar la URL remota del repositorio usando el comando git remote set-url.

git remote set-url origin git@github.com:usuario/repositorio.git

Este comando cambia el origen del repositorio para que Git deje de usar HTTPS y empiece a usar SSH.

Después podemos verificar nuevamente la configuración:

git remote -v

La salida esperada sería algo como:

origin  git@github.com:usuario/repositorio.git (fetch)
origin  git@github.com:usuario/repositorio.git (push)

3. Probar la conexión SSH con GitHub

Antes de intentar descargar ramas o actualizar el proyecto, conviene probar que la llave SSH realmente esté funcionando.

ssh -T git@github.com

Si la autenticación es correcta, GitHub responderá con un mensaje indicando que la conexión fue exitosa, aunque no permita acceso de shell. Esto es normal.

Una respuesta esperada puede ser similar a:

Hi usuario! You've successfully authenticated, but GitHub does not provide shell access.

Con eso confirmamos que la autenticación SSH ya está funcionando.

4. Descargar información actualizada del repositorio

Una vez configurada la URL SSH, podemos ejecutar:

git fetch origin

Este comando descarga la información actualizada de las ramas remotas sin mezclar cambios todavía en la rama actual.

5. Cambiar a una rama remota

Si necesitamos crear una rama local a partir de una rama remota, podemos usar:

git checkout -b nombre-rama origin/nombre-rama

Sin embargo, en proyectos reales puede aparecer un error indicando que un archivo local tiene cambios y que Git necesita sobrescribirlo para cambiar de rama.

Un caso común en Laravel puede ser un archivo como:

config/app.php

6. ¿Por qué pasa este error?

Git protege los cambios locales para evitar que se pierdan accidentalmente. Si tenemos modificaciones en un archivo y la rama a la que queremos cambiar también modifica ese archivo, Git detiene el proceso.

A veces se intenta usar el comando assume-unchanged para que Git ignore temporalmente un archivo:

git update-index --assume-unchanged config/app.php

Este comando puede ayudar en algunos escenarios locales, pero no es una solución ideal para manejar archivos de configuración modificados en servidores o ambientes de demo.

Además, aunque un archivo esté marcado como assume-unchanged, Git aún puede bloquear operaciones si necesita proteger cambios locales antes de cambiar de rama.

7. Revisar si un archivo está marcado como assume-unchanged

Podemos revisar el estado del archivo con:

git ls-files -v config/app.php

Si el archivo aparece con una letra minúscula al inicio, significa que está marcado como assume-unchanged.

8. Quitar assume-unchanged

Antes de resolver el conflicto, es recomendable quitar esa marca para que Git vuelva a tratar el archivo normalmente.

git update-index --no-assume-unchanged config/app.php

9. Opción segura: guardar temporalmente los cambios con stash

Si necesitamos conservar los cambios locales del archivo, podemos guardarlos temporalmente con git stash.

git stash push -m "Backup config app" -- config/app.php

Después ya podemos intentar cambiar de rama:

git checkout -b nombre-rama origin/nombre-rama

Y si necesitamos recuperar los cambios guardados:

git stash pop

Si al recuperar los cambios aparecen conflictos, deberán resolverse manualmente.

10. Opción rápida: descartar cambios locales

Si los cambios locales no son importantes, podemos descartarlos.

git restore config/app.php

Después intentamos nuevamente cambiar de rama:

git checkout -b nombre-rama origin/nombre-rama

Esta opción debe usarse con cuidado, porque elimina los cambios locales del archivo.

11. Mejor práctica en Laravel: usar .env para configuración por ambiente

En Laravel, lo más recomendable es evitar modificar archivos como config/app.php directamente en cada servidor. Si una configuración cambia dependiendo del ambiente, lo ideal es manejarla desde el archivo .env.

Por ejemplo, en lugar de dejar un valor fijo dentro de config/app.php, podemos leerlo desde una variable de entorno:

'custom_product' => env('APP_CUSTOM_PRODUCT', false),

Y en el archivo .env del servidor:

APP_CUSTOM_PRODUCT=true

De esta manera cada ambiente puede tener su propia configuración sin modificar archivos versionados en Git.

12. Flujo recomendado completo

Un flujo seguro para este tipo de situación sería:

cd /ruta/general/del/proyecto

git remote -v

git remote set-url origin git@github.com:usuario/repositorio.git

git remote -v

ssh -T git@github.com

git fetch origin

git update-index --no-assume-unchanged config/app.php

git stash push -m "Backup config app" -- config/app.php

git checkout -b nombre-rama origin/nombre-rama

Si después necesitamos recuperar los cambios locales:

git stash pop

Conclusión

Cuando un proyecto deja de autenticarse con GitHub porque venció un access token, una buena solución es migrar la conexión del repositorio a SSH. Para que esto funcione, no basta con crear la llave SSH: también debemos cambiar la URL remota del repositorio.

Además, si Git bloquea un cambio de rama por archivos modificados, debemos decidir si queremos conservar esos cambios con git stash o descartarlos con git restore.

En proyectos Laravel, la recomendación más limpia es mantener los archivos de configuración versionados sin modificaciones locales y mover los valores específicos de cada ambiente al archivo .env. Esto evita conflictos, mejora el flujo de despliegue y reduce errores al trabajar con ramas en Git.

Si necesitas ayuda para crear un proyecto de software en Maria Tech contamos con los expertos para apoyarte.

GitHub

Al crear el repositorio nosotros te recomendamos que lo dejes vacío ya que esto evitará que tengamos que hacer un commit extra al momento de sincronizar el proyecto.
Ignora estos documentos a menos que los necesites:

• Read me.
• Gitignore.
• Licence.

Inicializar proyecto

Desde la terminal (consola) ingresamos a nuestra carpeta.

cd /ruta/denuestra/carpeta

Una vez estando en nuestra carpeta ejecutamos los siguientes comandos:

1. git init
2. git add .
3. git commit -am “Inicialización del proyecto”

Una vez que ya tenemos inicializado nuestro proyecto procedemos a sincronizar la información, los siguientes comandos te los da el mismo GitHub al momento de crear el repositorio vacío.

git remote add origin git@github.com:tusuario/turepositorio.git
git branch -M main
git push -u origin main

Si todo ha ido bien ya podrás ver tu proyecto sincronizada con tu repositorio.

Si necesitas ayuda para crear un proyecto de software en Maria Tech contamos con los expertos para apoyarte.

• Estamos trabajando con configuraciones temporales o de prueba.
• Tenemos varios clientes y cada uno tiene su propia configuración.

Para estos casos el archivo .gitignore no es el ideal ya que si requerimos esos archivos pero no con las mismas configuraciones.
Aquí es cuando usamos el comando git update-index junto la opción –assume-unchanged.

• git update-index: Modifica el índice de los archivos.
• –assume-unchanged: Indica que se ignora al archivo aún así este tenga modificaciones, sería cómo sacarlo del seguimiento.
• –no-assume-unchanged: Indica que se le debe dar seguimiento nuevamente al archivo.

Sintaxis

Quitar seguimiento

 git update-index --assume-unchanged "path/to/file"

Volver a dar seguimiento

 git update-index --no-assume-unchanged "path/to/file"

Asegúrate de escribir bien la ruta y extensión del archivo.

Si necesitas ayuda para crear un proyecto de software en Maria Tech contamos con los expertos para apoyarte.

Envíanos un WhatsApp o escríbenos al correo y con gusto te ayudaremos.