Instalar Git en Windows para compatibilidad con repositorio de Linux

De

Quiero instalar git en Windows para allí desarrollar un programa, pero quiero que tenga compatibilidad con linux pues voy a usar un repositorio de un programa que lo estoy desarrollando en Linux pero también allí mismo en el repositorio voy a desarrollar el mismo programa pero para Windows

Instalación de Git en Windows

  1. Descarga Git para Windows desde la página oficial:
    👉 https://git-scm.com/download/win

  2. Durante la instalación en la versión de Git 2.51.0 de 64 bit aparece una opción desmarcada en la primer ventana importante:

NEW Add a Git Bash Profile to Windows Terminal


La opción "(NEW!) Add a Git Bash Profile to Windows Terminal" sirve para que, si usas el Windows Terminal (la app moderna de consola de Windows 10/11), se cree automáticamente un perfil con Git Bash. Así, podrás abrir Git Bash desde allí sin tener que configurarlo manualmente.

¿Conviene marcarlo?

  • ✅ Sí, márcalo si usas Windows Terminal (la aplicación que suele venir preinstalada en Windows 10 actualizado y en Windows 11). Te facilita cambiar entre PowerShell, CMD y Git Bash en el mismo lugar.

  • ❌ No es obligatorio. Si prefieres usar el acceso directo de Git Bash que se instala en el menú inicio, puedes dejarlo desmarcado sin problema.

👉 En resumen:

  • Si quieres integrar todo en Windows Terminal, márcalo.

  • Si no usas Windows Terminal, no hace falta.



Esa pantalla es simplemente para definir dónde se crearán los accesos directos en el menú inicio de Windows.

Opciones:

  • Dejarlo como "Git" (recomendado):
    Creará una carpeta en el menú inicio con accesos a Git Bash, Git GUI, y otras utilidades. Es lo más cómodo para encontrarlos después.

  • Cambiar el nombre:
    Si quieres que aparezca con otro nombre (ejemplo: "Desarrollo" o "Herramientas Git"). No afecta el funcionamiento.

  • Marcar "Don't create a Start Menu folder":
    No se crearán accesos en el menú inicio. Solo podrías abrir Git Bash buscándolo en el explorador o con Windows Terminal.

✅ Recomendación: déjalo como viene (en "Git") y presiona Next.
Así luego encontrarás fácilmente los accesos directos en el menú inicio.

¿Quieres que te vaya guiando paso a paso cada pantalla del instalador de Git hasta el final, explicándote qué marcar en cada una para tu caso de desarrollo multiplataforma?



En esta pantalla el instalador de Git te pide elegir el editor de texto por defecto que Git usará cuando necesites editar mensajes de commit, resolver conflictos de merge, o abrir archivos de configuración. Esta elección es importante porque cada vez que Git requiera abrir un editor, recurrirá a esta configuración.

Opciones disponibles

Vim (por defecto en Git)

  • Es un editor muy potente pero también difícil de aprender para quien no está familiarizado.
  • Su interfaz no es intuitiva: requiere recordar combinaciones de teclas especiales (por ejemplo, para salir hay que escribir :q o :wq).
  • Aunque es estándar en muchos sistemas Unix/Linux, en Windows puede resultar poco práctico si no tienes experiencia previa.

Nano

  • Muy común en Linux, es más fácil de usar que Vim (los comandos básicos aparecen abajo en pantalla, como ^O para guardar o ^X para salir).
  • Es ligero, rápido y funciona en terminal sin interfaz gráfica.
  • Ideal si quieres algo minimalista y no necesitas un editor sofisticado.
  • Recomendado si sueles trabajar mucho en servidores Linux por consola y quieres la misma experiencia en Windows.

Notepad++

  • Es un editor ligero, rápido y fácil de usar.
  • Tiene interfaz gráfica, menús, pestañas y coloreado de sintaxis.
  • Es una buena opción si quieres un editor simple pero potente sin tanta curva de aprendizaje.
  • Si lo eliges, Git abrirá Notepad++ cada vez que requiera edición.

Visual Studio Code

  • Es probablemente la mejor opción hoy en día si ya lo usas o planeas usarlo.
  • Ofrece integración con Git, resaltado de sintaxis avanzado, autocompletado, extensiones, y una experiencia moderna.
  • Muy recomendable si trabajas en proyectos medianos o grandes y ya lo tienes instalado.
  • Permite que, cuando Git abra el editor, dispongas de un entorno cómodo y uniforme tanto en Windows como en Linux (VS Code también existe para Linux).

Sublime Text

  • Editor gráfico muy rápido, ligero y muy popular hace algunos años.
  • Tiene coloreado de sintaxis excelente y una interfaz limpia.
  • La desventaja es que no es totalmente libre, su licencia es propietaria (aunque puedes usar la versión gratuita con notificaciones de compra).
  • Puede ser una buena opción si ya lo usas, pero hoy en día VS Code suele ofrecer más por menos.

Atom

  • Fue creado por GitHub como un editor moderno, pero ya está descontinuado desde 2022.
  • Aunque todavía funciona, ya no recibe actualizaciones ni parches de seguridad.
  • No es recomendable para nuevos proyectos, salvo que ya estés muy acostumbrado a usarlo.

VSCodium

  • Es una versión libre y sin telemetría de Visual Studio Code.
  • Funciona exactamente igual que VS Code (mismos atajos, mismas extensiones) pero con la ventaja de que es 100% software libre.
  • Es una gran opción si prefieres evitar productos cerrados de Microsoft, y además se integra perfectamente en Linux y Windows.
  • Muy recomendable para proyectos de software libre (como es tu caso), porque mantienes coherencia con tu filosofía de desarrollo.

¿Cuál elegir?

  • Si vienes del mundo Linux y estás cómodo con Vim, puedes dejarlo, o Nano si quieres un editor sencillo para consola y estás acostumbrado a usarlo en Linux.
  • Si quieres algo muy simple y rápido, elige Notepad++.
  • Si quieres un entorno de desarrollo moderno, con posibilidad de aprovecharlo también para tu programación en Python/Qt, elige Visual Studio Code.


Si luego quieres cambiarlo

Más adelante, si en algún momento quieres cambiarlo, puedes hacerlo con el siguiente comando en la terminal:

git config --global core.editor "code --wait"

De esa forma Git usará siempre Visual Studio Code para abrir cualquier archivo de texto que necesite durante tus operaciones.



Esta pantalla está preguntando qué nombre debe tener la rama inicial cuando cree un nuevo repositorio con git init (en caso de crearlo con git init).

Opción 1: Let Git decide

  • Git usará su valor por defecto, que históricamente ha sido master.
  • Aunque sigue funcionando, muchas comunidades y servicios (como GitHub y GitLab) han pasado a usar main como rama inicial por defecto.
  • Si eliges esto, en Windows crearás repos con rama master, mientras que en Linux o en plataformas como GitHub lo más probable es que se creen con main.

Eso puede generar pequeñas diferencias.

Opción 2: Override the default branch name

  • Aquí puedes especificar un nombre fijo para la rama inicial de tus nuevos repositorios.

  • Lo más común hoy es escribir:

    • main → estándar actual en GitHub, GitLab y la mayoría de proyectos modernos.
    • Alternativas: trunk, development, etc., pero son menos habituales.
    • Si elijo main, cada vez que use git init tendre coherencia con lo que ya ofrecen las plataformas de hosting, evitando que luego tenga que renombrar ramas.

✅ Recomendación práctica

Dado que mi proyecto será multiplataforma Linux + Windows y además estara hospedo en un repositorio compartido (GitHub):

👉 Marco "Override the default branch name for new repositories" y pongo main en el cuadro de texto.

Así garantizo que en ambos sistemas mis repositorios arranquen con la misma rama inicial que GitHub usa por defecto.



Esta pantalla define cómo quieres que Git se integre con el PATH de Windows, es decir, desde dónde podrás ejecutar los comandos git.

Opción 1: Use Git from Git Bash only

  • Git solo estará disponible dentro de Git Bash.
  • No podrás usar git desde el Símbolo del sistema (CMD) ni desde PowerShell.
  • Es la opción más conservadora, pero limita tu flexibilidad.

Opción 2: Git from the command line and also from 3rd-party software ✅ (Recomendada)

  • Añade Git al PATH de Windows, pero sin incluir las herramientas Unix adicionales.
  • Así podrás ejecutar git desde Git Bash, CMD, PowerShell, Windows Terminal, e incluso otros programas que busquen Git en el sistema.
  • Es la mejor opción si planeas trabajar con repositorios desde Qt Creator, VS Code/VSCodium, PyCharm, etc., porque estos IDEs necesitan encontrar git en el PATH.
  • No interfiere con los comandos nativos de Windows.

Opción 3: Use Git and optional Unix tools from the Command Prompt

  • Añade Git y todas las utilidades Unix (ls, cat, find, sort, etc.) al PATH global.
  • Problema: sobrescribe herramientas nativas de Windows (por ejemplo, find de Windows no es lo mismo que find de Unix).
  • Puede causar conflictos si usas scripts o programas que dependen de las utilidades originales de Windows.
  • Solo recomendado si ya trabajas siempre con estilo Unix y sabes que no afectará a tu flujo.

 Recomendación práctica para mi

Elige "Git from the command line and also from 3rd-party software" (la segunda opción). Así tendrás Git accesible desde cualquier terminal y desde tus IDEs (Qt Creator, VS Code, etc.), sin arriesgarte a romper herramientas nativas de Windows.

Cómo comprobar que Git quedó bien instalado y accesible desde cualquier terminal en Windows

 1. Abrir Git Bash

  1. Ve al menú inicio y abre Git Bash.

  2. Escribe:

    git --version

    → Si Git está bien instalado, deberías ver algo como:

    git version 2.51.0.windows.1

 2. Abrir CMD (Símbolo del sistema)

  1. Presiona Win + R, escribe cmd y pulsa Enter.

  2. En la ventana de CMD, ejecuta:

    git --version

    → Debería devolverte la misma versión de Git que en Git Bash. Esto confirma que Git está en el PATH de Windows y accesible para programas externos.

 3. Abrir PowerShell

  1. Abre PowerShell (búscalo en el menú inicio).

  2. Escribe:

    git --version

    → Si también responde con la versión de Git, significa que tu configuración de PATH es correcta en todos los entornos.

4. Verificar integración en IDEs

  • Abre Qt Creator o Visual Studio Code/VSCodium.
  • Crea un proyecto o abre una carpeta con un repositorio Git.
  • Si Git aparece en las opciones de control de versiones (por ejemplo, en VS Code verás la pestaña de "Source Control"), entonces el IDE está detectando Git en el PATH.

Posibles problemas y soluciones

  • Si CMD o PowerShell dicen “git no se reconoce como un comando” → significa que no está en el PATH.

    • Solución rápida: reinstalar Git y asegurarte de elegir la opción "Git from the command line and also from 3rd-party software".
  • Si Git Bash funciona pero los demás no → seguramente elegiste la primera opción (Git Bash only).

Con esto ya puedes estar seguro de que Git quedó instalado y listo para usarse tanto desde terminales como desde tus herramientas de desarrollo.



Esta pantalla define qué cliente SSH usará Git en Windows cuando trabajes con repositorios remotos (por ejemplo en GitHub, GitLab o un servidor propio). SSH es importante porque te permite conectarte de manera segura con claves en lugar de contraseñas.

Opción 1: Use bundled OpenSSH (recomendada)

  • Git instalará y usará su propia versión de ssh.exe incluida con Git for Windows.
  • Es la opción más sencilla y confiable: todo funciona directamente sin configuraciones adicionales.
  • Ideal si todavía no tienes configurado OpenSSH en tu sistema.

Opción 2: Use external OpenSSH

  • Git no usará su ssh.exe, sino el que encuentre en el PATH del sistema.
  • Esto tiene sentido si ya configuraste un entorno OpenSSH en Windows (ejemplo: usando el cliente OpenSSH que viene integrado en Windows 10/11 o el que instalaste con WSL).
  • Puede ser útil si quieres que todas tus aplicaciones compartan la misma configuración SSH (por ejemplo, Git, SCP, rsync, etc.).

✅ Recomendación para mi caso

Como estoy configurando Git en Windows para trabajar con repositorios de un proyecto que también uso en Linux:

👉 Eligo "Use bundled OpenSSH".

  • Es más simple, viene listo para usar y no requiere que configures nada extra en Windows.
  • Después, puedes generar tus claves SSH con ssh-keygen y usarlas tanto en Windows como en Linux para acceder al mismo repositorio.

⚡ Consejo adicional: Una vez que termines la instalación, te conviene verificar qué versión de SSH estás usando:

ssh -V

Y luego configurar, si las usas, tus claves SSH en:

C:\Users\TuUsuario\.ssh\

de la misma forma que en Linux (~/.ssh/).

Lo aclaro desde cero. En Linux normalmente sí se usan claves SSH para Git (GitHub, GitLab, servidores privados, etc.), pero puede pasar que hayas trabajado solo con HTTPS (https://...) y usuario/contraseña/token, sin notar la parte de SSH.

¿Qué es una clave SSH y para qué sirve?

  • Una clave SSH es como un par de llaves:

    • Una pública (se guarda en GitHub/GitLab o en el servidor).
    • Una privada (se guarda en tu computadora).
  • Cuando conectas con git@github.com:usuario/repositorio.git, Git usa esas llaves para comprobar tu identidad sin pedirte usuario/contraseña cada vez.
  • Es más seguro y más cómodo que usar HTTPS.

 Verificar si ya tienes claves SSH en Linux

  1. Abre la terminal en Linux.

  2. Escribe:

    ls -l ~/.ssh/

  3. Si ves archivos como:

    • id_rsa y id_rsa.pub, o
    • id_ed25519 y id_ed25519.pub entonces ya tienes claves creadas.

La .pub es la clave pública; la otra es la privada.

Generar una clave SSH (Linux o Windows)

Si no tienes, puedes generar una nueva en cualquiera de los dos sistemas (Linux o Windows, da igual). Por ejemplo, en Linux:

ssh-keygen -t ed25519 -C "tuemail@ejemplo.com"
  • Te pedirá una ruta (puedes aceptar la predeterminada: ~/.ssh/id_ed25519).
  • Te pedirá una passphrase (opcional, pero recomendable).

Esto genera dos archivos:

  • ~/.ssh/id_ed25519 → clave privada (NO se comparte).
  • ~/.ssh/id_ed25519.pub → clave pública (esta sí se copia a GitHub/GitLab).

Usar la misma clave en Windows

Si ya tienes tu clave en Linux, puedes copiarla a Windows:

  1. Copia los archivos id_ed25519 e id_ed25519.pub a:

    C:\Users\TuUsuario\.ssh\
  2. Asegúrate de que en Windows también se use OpenSSH (ya sea el que viene con Git o el de Windows).

  3. Comprueba con:

    ssh -T git@github.com

    Debería responder con algo como:

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

Conclusión

  • Si nunca configuraste claves SSH en Linux, probablemente usabas HTTPS con usuario/token.
  • Lo mejor para tu flujo Linux + Windows es generar una sola clave SSH (en Linux o en Windows) y usar la misma en ambos sistemas copiando los archivos al directorio .ssh.
  • Luego, agregas la clave pública en tu cuenta de GitHub/GitLab, y listo: podrás clonar y hacer push/pull sin contraseñas.



Esta pantalla define qué biblioteca SSL/TLS usará Git para validar las conexiones HTTPS (por ejemplo, cuando haces git clone https://... o git push si usas HTTPS en lugar de SSH).

🔹 Opción 1: Use the OpenSSL library

  • Git trae su propio OpenSSL y lo usa para validar certificados.
  • Funciona igual en cualquier sistema, independientemente de la configuración de Windows.
  • Es útil si quieres una experiencia homogénea entre Linux y Windows, ya que Linux también usa OpenSSL.
  • Pero implica que Git mantiene su propio archivo de certificados (ca-bundle.crt).

🔹 Opción 2: Use the native Windows Secure Channel library ✅ (recomendada en Windows)

  • Git usará el sistema de certificados de Windows.
  • Esto significa que confiará en los mismos certificados que el resto de tu sistema (navegadores, aplicaciones, etc.).
  • Es más sencillo porque no tienes que preocuparte por mantener actualizados los certificados de OpenSSL: Windows ya se encarga.
  • También es más compatible en entornos de empresa con certificados internos o proxys corporativos.

✅ Recomendación práctica

Para mi caso (desarrollo personal, multiplataforma Linux/Windows, repositorios en GitHub o GitLab): 👉 Elijo "Use the native Windows Secure Channel library".

  • En Windows te evitará problemas con certificados.
  • En Linux seguirás usando OpenSSL, pero eso no importa porque Git maneja bien ambas configuraciones.
  • Es la opción que recomiendan los propios desarrolladores de Git for Windows en la mayoría de escenarios.


En esta pantalla de instalación de Git for Windows, se pide decidir cómo manejar las diferencias en los saltos de línea entre sistemas operativos. Este detalle, aunque parece menor, es crucial cuando se trabaja en proyectos multiplataforma (Windows, Linux y macOS).

🌍 El problema de los finales de línea

  • Windows usa el estilo CRLF (\r\n) para indicar un salto de línea.
  • Linux y macOS usan el estilo LF (\n).

Cuando se comparten archivos de texto (código fuente, scripts, configuraciones) en un repositorio, estas diferencias pueden causar conflictos, cambios innecesarios en los commits o incluso errores de ejecución (por ejemplo, en scripts de Python o Bash).

🔹 Opciones disponibles

1. Checkout Windows-style, commit Unix-style line endings ✅ (recomendada en Windows)

  • Al descargar archivos (checkout), Git los convierte a CRLF para que se vean y editen cómodamente en Windows.
  • Al hacer commit, Git los guarda en el repositorio con LF, garantizando compatibilidad con Linux y macOS.
  • Es la mejor opción para proyectos compartidos entre Windows y sistemas Unix.

2. Checkout as-is, commit Unix-style line endings

  • Git no convierte los archivos al descargarlos: se mantienen tal como están en el repositorio.
  • Al hacer commit, los normaliza a LF.
  • Recomendado si se trabaja principalmente en Linux/macOS y solo ocasionalmente en Windows, porque evita conversiones innecesarias.

3. Checkout as-is, commit as-is

  • Git no hace ninguna conversión, ni al descargar ni al guardar.
  • El repositorio puede terminar con una mezcla de CRLF y LF, lo cual suele generar problemas en equipos que colaboran desde distintos sistemas.
  • No se recomienda para proyectos colaborativos, solo en casos muy específicos.

✅ Conclusión

Para la mayoría de los usuarios de Windows que trabajan en proyectos colaborativos multiplataforma, la opción más segura es:

“Checkout Windows-style, commit Unix-style line endings”

De esta forma:

  • En tu editor de Windows tendrás saltos de línea normales de Windows (CRLF).
  • En el repositorio, Git guardará siempre los archivos con saltos de línea de Unix (LF), garantizando compatibilidad y consistencia con Linux y macOS.

Tip adicional para el blog: Este ajuste corresponde a la configuración interna core.autocrlf de Git:

  • true → Checkout CRLF, Commit LF.
  • input → Checkout sin cambios, Commit LF.
  • false → Sin conversiones.




En este paso de la instalación de Git for Windows, se debe elegir qué emulador de terminal se usará para abrir Git Bash, que es la consola incluida con Git. La elección afecta la comodidad al trabajar y la compatibilidad con ciertos programas.

🔹 Opciones disponibles

1. Use MinTTY (the default terminal of MSYS2) ✅ (opción recomendada)

  • MinTTY es un emulador de terminal moderno y avanzado.

  • Ofrece:

    • Ventana redimensionable.
    • Soporte para fuentes Unicode (ideal para caracteres especiales, acentos, emojis).
    • Selección de texto en áreas no rectangulares.
  • Es mucho más cómodo que la consola clásica de Windows.
  • Limitación: algunos programas de Windows muy interactivos (como ciertas versiones de Python o Node.js en modo interactivo) no funcionan directamente en MinTTY. En esos casos se puede usar un comando auxiliar (winpty) para ejecutarlos correctamente.

2. Use Windows' default console window

  • Utiliza la consola por defecto de Windows (cmd.exe).
  • Es más básica y con menos características gráficas.

  • Sus limitaciones históricas:

    • Antes de Windows 10 no permitía redimensionar fácilmente la ventana.
    • Manejo pobre de Unicode (se necesitaba configurar fuentes especiales).
    • Scrollback (historial) limitado.
  • La ventaja: mayor compatibilidad con programas que esperan ejecutarse directamente en un entorno Windows tradicional.

✅ Conclusión

Para la gran mayoría de usuarios, la mejor elección es:

👉 “Use MinTTY (the default terminal of MSYS2)”

De esta manera, se obtiene una experiencia moderna y cómoda al usar Git Bash, con soporte completo para caracteres internacionales y un entorno mucho más agradable que el viejo cmd.exe.

Si en algún momento se necesita ejecutar un programa que no funciona bien dentro de MinTTY, se puede recurrir al comando winpty como puente, sin necesidad de reinstalar Git.

📌 Tip: Esta configuración solo afecta a Git Bash. Si prefieres trabajar con Windows Terminal, puedes integrarlo después y tener lo mejor de ambos mundos: MinTTY para Git Bash independiente, y Git Bash también como perfil dentro de Windows Terminal.

🖥️ Cómo integrar Git Bash en Windows Terminal

Windows Terminal es la aplicación moderna de Microsoft que reemplaza al viejo cmd.exe y ofrece una experiencia mucho más cómoda con pestañas, temas y soporte Unicode. Una de sus grandes ventajas es que puedes añadir Git Bash como un perfil adicional, de modo que no tengas que abrirlo desde accesos separados.

Paso 1: Instalar Windows Terminal

  1. Abre la Microsoft Store.
  2. Busca Windows Terminal.
  3. Instálalo (es gratuito).
  4. Una vez instalado, lo encontrarás en el menú inicio.

Paso 2: Localizar Git Bash

Normalmente, Git Bash se instala en:

C:\Program Files\Git\bin\bash.exe

o en algunos casos:

C:\Program Files\Git\usr\bin\bash.exe

Verifica la ruta en tu sistema para asegurarte.

Paso 3: Configurar el perfil en Windows Terminal

  1. Abre Windows Terminal.
  2. Haz clic en la flecha hacia abajo (v) que está al lado de las pestañas.
  3. Selecciona Configuración (se abre en un archivo JSON en versiones antiguas, o en una interfaz gráfica en las más recientes).

  4. Si usas la interfaz gráfica, haz clic en + Agregar nuevo perfil.

    • Nombre: Git Bash
    • Comando: C:\Program Files\Git\bin\bash.exe
    • Icono (opcional): busca en C:\Program Files\Git\mingw64\share\git\git-for-windows.ico para usar el ícono oficial.

Si lo haces en JSON (versión antigua), agrega este bloque en la sección "profiles": { "list": [...] }:

{
  "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
  "name": "Git Bash",
  "commandline": "C:\\Program Files\\Git\\bin\\bash.exe",
  "icon": "C:\\Program Files\\Git\\mingw64\\share\\git\\git-for-windows.ico",
  "startingDirectory": "%USERPROFILE%"
}

🔹 Paso 4: Guardar y probar

  1. Guarda los cambios.
  2. Ahora, al abrir Windows Terminal, verás Git Bash en la lista de perfiles.
  3. Haz clic y tendrás Git Bash corriendo como una pestaña más junto a PowerShell o CMD.

🔹 Paso 5 (opcional): Hacer que Git Bash sea el perfil por defecto

  1. En la configuración de Windows Terminal, busca la opción Default profile.
  2. Selecciona Git Bash.
  3. De esta forma, cada vez que abras Windows Terminal, Git Bash será la sesión predeterminada.

✅ Conclusión

Con estos pasos, tendrás Git Bash integrado en Windows Terminal, disfrutando de:

  • Una experiencia moderna con pestañas.
  • Mejor soporte para caracteres y Unicode.
  • Temas y personalización.
  • Acceso rápido a PowerShell, CMD y Git Bash en un solo lugar.



En esta pantalla de instalación de Git for Windows, se define el comportamiento por defecto del comando git pull. Este comando combina dos pasos: primero descarga los cambios del repositorio remoto (git fetch) y luego los integra en la rama actual. Lo que se elige aquí determina cómo se realiza esa integración.

Opciones disponibles

1. Fast-forward or merge ✅ (recomendado por defecto)

  • Si los cambios remotos pueden aplicarse directamente (no hay commits locales que entren en conflicto), Git hace un fast-forward: mueve el puntero de la rama sin crear commits extras.
  • Si existen divergencias (commits en local y en remoto), Git hará un merge commit automático para combinar las ramas.
  • Ventaja: se conserva la historia completa de lo que ocurrió, sin reescribir commits.
  • Desventaja: la historia puede llenarse de merge commits si se trabaja en equipo con mucha frecuencia de pushes.

2. Rebase

  • En lugar de crear merges, Git reordena tus commits locales “encima” de los remotos.
  • Resultado: el historial queda más lineal y limpio, sin tantos merges.
  • Desventaja: reescribe commits locales, lo cual puede complicar si ya compartiste esos commits con otros.
  • Muy popular en proyectos donde se busca mantener un historial ordenado y sin bifurcaciones innecesarias.

3. Only ever fast-forward

  • Git solo actualizará la rama si puede hacerlo con un fast-forward limpio.
  • Si hay divergencias (commits diferentes en local y remoto), el git pull fallará.
  • Esto obliga a que el usuario resuelva manualmente la situación (con git merge o git rebase).
  • Es la opción más estricta, útil si se quiere evitar merges automáticos en el flujo de trabajo.

✅ Conclusión

La opción más equilibrada para la mayoría de usuarios y equipos es:

“Fast-forward or merge”

Con esta configuración, git pull será flexible: actualizará rápido cuando sea posible y, en caso de divergencia, generará un commit de merge automático para mantener todo sincronizado.

Quienes busquen un historial más lineal pueden preferir Rebase, y quienes quieran control absoluto pueden optar por Only fast-forward.

Tip adicional: Esta elección se puede modificar más adelante en cualquier repositorio con:

git config pull.rebase true   # para usar rebase
git config pull.ff only       # solo fast-forward
git config pull.ff false      # fast-forward o merge

¿Quieres que te prepare también un ejemplo visual para el blog (con esquemas simples de fast-forward, merge y rebase) para que tus lectores entiendan mejor las diferencias?



En esta pantalla de la instalación de Git for Windows, se pide elegir el credential helper, es decir, el sistema que gestionará tus credenciales de acceso (usuario, contraseña, token o claves) cuando te conectes a repositorios remotos.

Opciones disponibles

1. Git Credential Manager ✅ (recomendado)

  • Es una herramienta oficial y multiplataforma desarrollada para simplificar el manejo de credenciales.

  • Ventajas:

    • Guarda de manera segura tus credenciales en el sistema (Windows Credential Manager, macOS Keychain, o Linux Secret Service).
    • Compatible con HTTPS en GitHub, GitLab, Bitbucket, Azure DevOps, etc.
    • Soporta autenticación con tokens y autenticación en dos pasos (2FA).
    • Evita tener que ingresar usuario/contraseña en cada git push o git pull.
  • Es la opción más práctica si planeas usar HTTPS en lugar de SSH.

2. None

  • Git no usará ningún gestor de credenciales.
  • Cada vez que hagas una operación remota (git push, git pull, git fetch), tendrás que escribir usuario y contraseña (o token).
  • Puede ser útil si solo usarás claves SSH para autenticarte con GitHub/GitLab, ya que en ese caso Git Credential Manager no es necesario.

✅ Conclusión

Para la mayoría de usuarios que usan repositorios en plataformas como GitHub o GitLab:

👉 La mejor opción es “Git Credential Manager”.

De esta forma, podrás iniciar sesión una sola vez (con tu cuenta, token o 2FA) y Git recordará tus credenciales de forma segura en Windows.

Si en tu flujo de trabajo vas a usar exclusivamente SSH con llaves (en lugar de HTTPS), puedes elegir “None”, pero en escenarios mixtos es más cómodo mantener el Credential Manager activado.

📌 Tip extra: Después de la instalación, siempre se puede cambiar esta configuración:

git config --global credential.helper manager-core   # habilitar Git Credential Manager
git config --global --unset credential.helper        # deshabilitarlo



En esta última pantalla de instalación de Git for Windows, se muestran opciones adicionales que afectan el rendimiento y las características avanzadas del sistema de archivos.

Enable file system caching ✅ (recomendado)

Esta opción viene marcada por defecto y es recomendable dejarla activada. Lo que hace es habilitar la caché del sistema de archivos, de modo que Git pueda leer grandes cantidades de datos en memoria en lugar de acceder al disco constantemente. El resultado es una mejora notable de rendimiento, especialmente en repositorios grandes.

Enable symbolic links

Esta opción permite que Git maneje correctamente los enlaces simbólicos (symlinks), que son atajos especiales a archivos o directorios. En sistemas Linux y macOS son muy comunes, pero en Windows requieren permisos especiales (SeCreateSymbolicLink). Si trabajas con repositorios que usan symlinks, marcar esta casilla puede ser útil. Sin embargo, si tu proyecto no los usa o no tienes permisos de administrador para crearlos, no es necesario activarla.

Conclusión

La mejor configuración para la mayoría de los usuarios es dejar marcada:

Enable file system caching 

y dejar desmarcada Enable symbolic links, a menos que sepas que tu proyecto los necesita. Con esto se garantiza un mejor rendimiento en Git sin complicaciones adicionales.

INSTALACIÓN COMPLETA

Una vez completada la instalación de Git for Windows, en el menú inicio aparecen tres accesos principales: Git GUI, Git CMD y Git Bash. Cada uno cumple una función distinta y conviene explicar sus diferencias para que el lector sepa cuál utilizar en cada caso.

Git GUI

Es la interfaz gráfica de Git incluida en la instalación. Permite realizar las operaciones más comunes (commit, push, pull, merge) mediante menús y botones, sin necesidad de recordar comandos. Es ideal para quienes prefieren un entorno visual, aunque sus funciones son más limitadas que las de un IDE moderno con integración Git (como VS Code).

Git CMD

Este acceso abre la consola de Windows (cmd.exe) con Git configurado en el PATH, lo que significa que se pueden ejecutar comandos de Git directamente. La ventaja es que funciona como la consola nativa de Windows, pero puede resultar más básica y menos cómoda para trabajar con repositorios grandes.

Git Bash

Es el entorno más completo y recomendado. Git Bash abre una terminal basada en MinTTY con un intérprete tipo Unix, lo que permite usar no solo los comandos de Git, sino también herramientas del ecosistema Linux como ls, cat, grep y ssh. Esto lo convierte en la mejor opción para trabajar en proyectos multiplataforma (Linux y Windows) porque ofrece un entorno muy similar al que se utiliza en sistemas basados en Unix.

Conclusión

Tras la instalación, lo más aconsejable es utilizar principalmente Git Bash para un flujo de trabajo cómodo y consistente entre Windows y Linux. Git CMD queda como alternativa ligera, y Git GUI puede servir a quienes prefieren un enfoque visual, aunque hoy en día suele ser más práctico usar un editor moderno con integración Git como VS Code o VSCodium.

Dios les bendiga

Referencias

Git for Windows – Official Site
https://gitforwindows.org

Git Documentation – Git SCM
https://git-scm.com/doc

Pro Git Book (Scott Chacon and Ben Straub, Apress)
https://git-scm.com/book/en/v2

Git Credential Manager – Microsoft Docs
https://learn.microsoft.com/en-us/windows/gitcredentialmanager

Qt for Python Documentation (PySide6)
https://doc.qt.io/qtforpython/

Qt Creator Manual – Qt Documentation
https://doc.qt.io/qtcreator/



Comentarios

Publicar un comentario