Sincronización de configuraciones entre varios PCs mediante Git

Trabajar con varios ordenadores a la vez se ha vuelto algo totalmente normal: un sobremesa potente en casa, un portátil para moverte, quizá incluso un tercer equipo en la oficina. El problema llega cuando quieres mantener la misma configuración, los mismos proyectos y la misma versión del código en todos ellos sin volverte loco copiando carpetas con un pendrive o mandándote zips por correo.

Si te suena la situación de tener un PC de escritorio donde programas a gusto, comprar un portátil nuevo para seguir currando en los mismos proyectos y no saber cómo sincronizarlo todo, Git y GitHub (u otras plataformas remotas) son justo lo que necesitas. La idea es simple: tener un repositorio central en la nube y que todos tus equipos se conecten a él para subir y bajar cambios, manteniendo tanto el código como ciertas configuraciones alineadas.

Qué significa sincronizar configuraciones y código entre varios PCs con Git

Cuando hablamos de “sincronizar configuración y código” entre tu sobremesa y tu portátil (o entre Windows y macOS), en realidad nos referimos a dos cosas distintas pero relacionadas: por un lado, los archivos de tu proyecto (código, recursos, documentación) y, por otro, la configuración que usas para trabajar (ajustes del editor, plantillas, scripts, dotfiles, etc.).

Git está pensado principalmente para versionar y compartir el código fuente, pero con un poco de organización también puedes utilizarlo para replicar cierta configuración entre máquinas, siempre que se trate de archivos dentro de una carpeta de proyecto o de repositorios específicos de configuración (por ejemplo, un repo de dotfiles con tus ajustes de terminal, alias, etc.).

En un escenario típico, tendrás en casa un PC de sobremesa con tu IDE, tus proyectos y tus repositorios ya creados, y quieres que tu portátil del trabajo tenga exactamente los mismos repositorios, con la misma rama principal y los mismos cambios. Así, podrás editar código en cualquiera de los dos, hacer commit y sincronizar vía GitHub u otro remoto.

También es habitual que te preguntes si debes usar el mismo usuario y correo de Git en todos los equipos. Para que GitHub asocie correctamente tus commits a tu cuenta, el correo que configures en cada máquina debe coincidir con el registrado en tu perfil de GitHub. El nombre puede variar, pero el correo es clave para que todo quede vinculado a ti.

En resumen, el objetivo es que puedas abrir tu proyecto en el sobremesa, cerrar, irte con tu portátil, seguir programando y, al volver, que tu equipo principal reciba los cambios sin conflictos, manteniendo siempre una única “fuente de verdad” del código en el remoto.

Configurar Git correctamente en cada dispositivo

Antes de ponerte a clonar repositorios y hacer commits, es fundamental que tengas Git bien configurado en todos los equipos donde vayas a trabajar. Esto incluye instalar Git, configurar tu nombre y correo y, si usas GitHub, asegurarte de que tu identidad es coherente y que tus credenciales funcionan sin fricción.

Lo primero es instalar Git en cada sistema operativo. Una vez instalado, abre la consola (Terminal en macOS o Linux, PowerShell o Git Bash en Windows) y configura tus datos de usuario con estos comandos:

git config –global user.name «Tu Nombre»
git config –global user.email «tu-correo@ejemplo.com»

Lo realmente importante es que el correo sea el mismo que tienes en GitHub, porque es lo que GitHub usa para asociar tus commits a tu cuenta. El nombre es más flexible: podrías incluso elegir nombres distintos por equipo, aunque en la práctica no tiene mucho sentido si eres la única persona que trabaja en el proyecto. Lo lógico es usar siempre el mismo nombre para que el historial se vea limpio y consistente.

Si alguna vez dudas de qué has configurado, puedes ejecutar:

git config –list

Este comando te mostrará un listado con tu user.name, user.email y otras opciones globales y locales. Si ves algo mal (por ejemplo, un email con una errata), puedes repetir los comandos anteriores para corregirlo. Conviene revisar esto en todos tus equipos, sobre todo cuando estrenas portátil nuevo.

Además, la consola de Git funciona prácticamente igual en Windows, macOS y Linux. Eso quiere decir que los comandos que aprendas en tu sobremesa con Windows te valdrán si en tu portátil tienes macOS o una distribución de Linux. Lo más relevante es que te familiarices con el flujo básico de trabajo (add, commit, push, pull) y que mantengas tu configuración alineada.

Cómo compartir el mismo repositorio entre sobremesa y portátil

Si ya tienes el proyecto creado en tu PC de escritorio y lo has subido a GitHub, la parte que te falta es conectar el portátil para que trabaje con ese mismo repositorio. Mucha gente se queda justo después de hacer el primer push al remoto, sin entender cómo continuar desde otra máquina.

La idea es muy sencilla: en el portátil no vas a crear un repositorio nuevo, sino que vas a clonar el que ya existe en GitHub. Eso crea una copia completa del historial y de los archivos en tu segundo equipo, con el remoto ya configurado.

En tu portátil, ve a la carpeta donde quieras tener el proyecto y ejecuta:

git clone https://github.com/tu-usuario/tu-repo.git

Tras ese comando, tendrás una carpeta tu-repo con el código y el historial completo. A partir de ahí, el flujo será el mismo en ambos equipos: haces cambios, usas git add para seleccionar archivos, git commit para registrar los cambios y git push para enviarlos al remoto. En el otro ordenador, ejecutarás git pull para traer esos commits nuevos.

Si eres principiante con Git, es normal que al principio te líes con la diferencia entre clone, pull y push. Piensa que git clone sólo se hace una vez por máquina, cuando quieres obtener el repo por primera vez. A partir de ahí, cada vez que quieras sincronizar, usarás pull para bajar cambios y push para subir los tuyos.

Trabajar desde varios equipos sin pisar tu propio trabajo

Uno de los miedos más habituales cuando usas varios PCs es la posibilidad de sobrescribir trabajo sin querer. La buena noticia es que Git está precisamente diseñado para evitar este tipo de desastres siempre que sigas unas reglas básicas y tengas la costumbre de hacer commits claros.

Por norma general, antes de empezar a tocar código en cualquiera de tus equipos, conviene hacer un git pull en la rama en la que vayas a trabajar. Así te aseguras de que tienes la versión más reciente del remoto y minimizas conflictos. Después, programas con normalidad, añades los archivos modificados y haces commit con un mensaje descriptivo.

Es muy recomendable que tus mensajes de commit expliquen bien qué has cambiado. Piensa en ti mismo dentro de dos semanas intentando entender por qué hiciste algo. Mensajes tipo “cambios varios” o “cositas” no ayudan a nadie. Incluye información como “corrige bug al compilar en Windows” o “añade sincronización automática entre equipos”.

Cuando termines una sesión de trabajo en casa, haces git push para subir los commits. Al llegar al trabajo, enciendes el portátil, haces git pull y continuarás justo desde ese punto. El proceso inverso es exactamente igual: trabajas en el portátil, haces push, y en casa haces pull antes de seguir.

En cuanto a los conflictos, aparecerán cuando hayas modificado las mismas líneas de un archivo en dos sitios distintos sin haber sincronizado entre medias. Git te avisará y te pedirá que resuelvas el conflicto de forma manual. No es algo dramático, pero cuanto mejor te acostumbres a sincronizar antes de empezar y al terminar, menos veces te pasará.

Algunas personas se plantean usar nombres de usuario distintos en cada dispositivo para “saber desde qué PC se hizo cada commit”. Técnicamente puedes hacerlo, pero en la práctica suele ser más un estorbo que una ayuda. Si todo lo haces tú, lo normal es que uses el mismo nombre en todas partes y que el detalle del dispositivo no tenga importancia real en el proyecto.

Sincronización casi en tiempo real: ¿es posible evitar tanto push/pull manual?

Cuando te acostumbras a trabajar en dos sistemas muy diferentes, por ejemplo desarrollando código en un Mac pero compilando y probando el juego en un PC con Windows, puede empezar a molestarte tener que estar continuamente haciendo push en un lado y pull en el otro de forma manual.

Git en sí mismo está pensado para una sincronización explícita, es decir, que llames tú a los comandos. No funciona como una carpeta de Dropbox que se actualiza “sola” al guardar una modificación. Sin embargo, hay trucos y herramientas que te pueden acercar a algo similar a la sincronización en vivo.

Una opción que muchos desarrolladores se plantean es utilizar servicios de almacenamiento en la nube (Drive, Dropbox, OneDrive) para sincronizar directamente la carpeta donde está el repositorio. Esto puede funcionar pero no es lo más recomendable, porque esos servicios no entienden la lógica interna de Git y, en determinados casos, podrían corromper el repositorio si hay cambios simultáneos o ficheros en uso.

Si tu idea es programar en un Mac mientras el juego sólo corre en Windows, podrías tener el repo principal en el PC y usar Git simplemente como “puente” entre máquinas. Haces commit en el Mac, subes a un remoto (por ejemplo GitHub o un repositorio privado en tu red local) y en el PC automatizas de algún modo el pull, ya sea con un script que se ejecute cada cierto tiempo o con una tarea programada que revise si hay cambios nuevos.

Por ejemplo, puedes crear un script en Windows que cada pocos minutos ejecute:

git fetch origin
git pull origin main

De esa manera, cada vez que guardes tus cambios en el Mac, hagas commit y push, el PC terminará descargando automáticamente la última versión pasada un breve intervalo. No es tan inmediato como una carpeta mágica que se actualiza sola, pero se le acerca bastante y evita el “dolor de cabeza repetitivo” de irte constantemente a la consola del PC para tirar de la rama.

En cualquier caso, recuerda que Git sigue necesitando commits coherentes. Aunque automatices parte del proceso de sincronización, conviene que mantengas la disciplina de agrupar cambios lógicos en cada commit y de revisar el historial de vez en cuando para asegurarte de que todo tiene sentido.

Sincronizar solo el equipo de trabajo vs. sincronizar organizaciones y equipos en GitHub

Hasta ahora nos hemos centrado en el uso individual de Git, es decir, tú con tus ordenadores y tus proyectos personales. Pero GitHub ofrece otra forma de “sincronización” que, aunque se parezca de nombre, está pensada para organizaciones, empresas y equipos más grandes: la sincronización de equipos con grupos de un proveedor de identidad (IdP).

Cuando la sincronización de equipos está habilitada en una organización de GitHub, es posible vincular un equipo de GitHub con un grupo de usuarios definido en tu IdP (por ejemplo, Azure AD, Okta, etc.). En cuanto se establece esa conexión, cualquier cambio de pertenencia en ese grupo de IdP se refleja automáticamente en GitHub: si un usuario entra o sale del grupo en el IdP, se añade o elimina del equipo correspondiente en GitHub.

Esto reduce la necesidad de actualizar manualmente la lista de miembros de los equipos en GitHub o de mantener scripts personalizados para automatizar esa tarea. Puedes incluso asignar un mismo grupo de IdP a varios equipos de GitHub, lo que resulta muy cómodo si compartes los mismos desarrolladores entre distintos repositorios o áreas de un proyecto.

Una vez que conectas un equipo de GitHub con un grupo del proveedor de identidad, la gestión de altas y bajas de ese equipo debe hacerse exclusivamente desde el IdP. Esto significa que ya no puedes administrar manualmente las pertenencias directamente en GitHub para ese equipo concreto; cualquier modificación debe pasar por el sistema de identidad central.

Sin embargo, conviene tener en cuenta algunas limitaciones. Por ejemplo, los equipos padre no pueden sincronizarse directamente con grupos de IdP. Si el equipo que te interesa está configurado como equipo padre dentro de la jerarquía de GitHub, tendrás que crear un equipo nuevo sin relaciones anidadas o reorganizar esa jerarquía para eliminar la condición de padre antes de poder vincularlo al IdP.

Otro punto importante es que esta sincronización de equipos no crea automáticamente equipos en GitHub cuando se crean grupos en el IdP, ni siquiera si tienes aprovisionamiento SCIM configurado. Para que la conexión funcione, el equipo tiene que existir primero en la organización de GitHub; después, lo vinculas al grupo. Y aunque el alta y la baja de miembros se controlen desde el IdP, el acceso de esos equipos a cada repositorio (permisos de lectura, escritura, admin, etc.) se sigue configurando desde GitHub.

Resumiendo: esta característica de sincronización viene de maravilla para organizaciones medianas o grandes con muchos usuarios, donde no quieres estar gestionando uno a uno quién pertenece a qué equipo. Pero es muy diferente a la sincronización de código y configuración entre tus propios PCs; son capas de sincronización complementarias, pero orientadas a necesidades distintas.

Pasos prácticos para poder trabajar en el mismo proyecto desde escritorio y portátil

Si eres completamente nuevo en Git y vienes de seguir un tutorial donde has creado el repositorio en tu ordenador de sobremesa, has hecho tu primer commit y lo has subido a GitHub, es normal que no sepas qué viene después para tener el mismo proyecto en tu portátil.

La secuencia general que deberías seguir es algo como esto: en tu PC de escritorio creas el proyecto (o lo conviertes en repo con git init), haces tus primeros cambios, los añades, haces commit y luego conectas con GitHub (con git remote add origin) y haces push a la rama principal. Este suele ser el punto donde terminan muchos tutoriales de iniciación.

En tu portátil, como hemos visto antes, simplemente clonas el repositorio desde GitHub usando git clone. A partir de ese momento, tanto el PC de escritorio como el portátil comparten el mismo remoto y la misma rama principal. El resto es cuestión de disciplina: antes de trabajar haces pull, después haces push.

Si ya has estado probando otras alternativas (sin saber muy bien qué sistema elegir) y tienes una mezcla de carpetas, copias manuales y servicios en la nube, puede que te hayas metido en un pequeño lío. La mejor estrategia suele ser elegir una única solución central (por ejemplo, GitHub con Git) y limpiar el resto de métodos improvisados para evitar que se mezclen versiones diferentes del mismo proyecto en sitios distintos.

Como desarrollador individual, puedes trabajar perfectamente en varios ordenadores usando Git y un proveedor remoto gratuito. Planes sin coste para repositorios privados y públicos están disponibles en varios servicios, con más que suficiente para un solo desarrollador. Lo que marcan la diferencia son las facilidades de integración con tus herramientas, la interfaz web que prefieras y alguna funcionalidad extra (issues, CI/CD, etc.), pero todas cumplen el papel de repositorio remoto para sincronizar tus equipos.

Recuerda, además, que no hace falta que utilices una interfaz gráfica si prefieres la consola, aunque muchos IDEs modernos (como Visual Studio, VS Code, IntelliJ, etc.) traen integrado soporte para Git. En el caso concreto de Visual Studio 2022 en Windows, puedes realizar commits, pushes y pulls desde el propio IDE, lo que hace que el proceso sea menos pesado si no te quieres mover a la terminal constantemente.

Al final, lo fundamental es que entiendas el concepto: el remoto actúa como punto central donde convergen los cambios que haces desde tus distintos ordenadores. Mientras respetes ese flujo (pull antes de trabajar, push al terminar, mensajes de commit claros), podrás saltar de máquina en máquina con la tranquilidad de saber que siempre estás usando la versión más reciente.

Con todo esto, la sincronización de configuraciones y código entre varios PCs mediante Git se convierte en algo bastante manejable: configuras correctamente tu usuario en cada máquina, usas un remoto confiable como núcleo de tu trabajo, decides si quieres un flujo manual o automatizado para los pulls y, si trabajas en una organización, te apoyas en la sincronización de equipos con el IdP para gestionar los accesos de forma centralizada. Una vez interiorizados estos pilares, cambiar de sobremesa a portátil o de Windows a Mac deja de ser un quebradero de cabeza y pasa a ser simplemente una cuestión de hacer commit, push y seguir trabajando donde lo dejaste.