Preguntas de Git en una entrevista de trabajo: 25 preguntas con respuestas

Git aparece en casi cualquier entrevista para desarrollador, tester o ingeniero DevOps: a veces como bloque aparte, a veces de pasada («¿cómo desharías un release fallido?»). Al entrevistador no le importa tanto que te sepas las opciones como que entiendas el modelo: qué es un commit, a qué apunta una rama, qué reescribe el historial. Aquí tienes las 25 preguntas más frecuentes, con respuestas del nivel que causa buena impresión.

Las preguntas van de lo básico a lo avanzado. Al responder en la entrevista, si puedes, da un ejemplo breve de tu experiencia: se valora más que recitar la documentación.

Preguntas básicas

1. ¿Qué es Git y en qué se diferencia un sistema de control de versiones distribuido de uno centralizado?

Git es un sistema de control de versiones distribuido: guarda el historial de cambios del proyecto y permite que varias personas trabajen en él en paralelo. En los sistemas centralizados (por ejemplo, SVN) el historial completo está en un único servidor y el desarrollador solo tiene una copia de trabajo. En Git cada clon contiene todo el historial, así que los commits, las ramas, la consulta del historial y las fusiones funcionan en local y sin red.

De ahí las ventajas prácticas: gran velocidad, trabajo sin conexión y ausencia de un punto único de fallo. Un servidor como GitHub o GitLab es, en Git, simplemente un acuerdo del equipo sobre cuál es la copia «principal», no una necesidad técnica.

2. ¿Cuáles son las tres áreas de trabajo de Git?

El directorio de trabajo (los archivos en disco), el índice o staging area (la instantánea preparada del próximo commit) y el repositorio local (la carpeta .git con el historial). git add lleva los cambios del directorio de trabajo al índice y git commit, del índice al repositorio.

Un buen detalle extra es mencionar una cuarta zona, el repositorio remoto, y los comandos git push y git fetch que trabajan con él.

3. ¿Para qué sirve el índice si se podría hacer commit directamente?

El índice permite construir el commit de forma consciente: de diez archivos modificados, hacer commit de los tres que pertenecen a una tarea y dejar el resto. Con git add -p incluso puedes elegir fragmentos concretos dentro de un archivo.

Es la base de los commits atómicos: un commit, un cambio lógico. Ese historial es fácil de leer, revisar, deshacer con revert y trasladar con cherry-pick.

4. ¿Qué es un commit desde el punto de vista interno de Git?

Un commit es un objeto que guarda una referencia a un árbol (tree), es decir, una instantánea de todos los archivos del proyecto, referencias a los commits padre, el autor, el committer, las fechas y el mensaje. Se identifica por un hash SHA-1 (las versiones nuevas tienen soporte experimental para SHA-256) de todo su contenido.

La idea clave: Git guarda instantáneas, no diffs. Los archivos sin cambios no se duplican: el árbol simplemente apunta al mismo blob. Como el hash depende del padre, es imposible modificar un commit antiguo sin cambiar los hashes de todos los posteriores.

5. ¿Qué es una rama y qué es HEAD?

Una rama no es más que un puntero móvil a un commit: un archivo en .git/refs/heads/ con un hash dentro. Por eso crear una rama en Git es instantáneo y no copia nada. Con cada commit nuevo, el puntero de la rama actual se mueve a él.

HEAD es el puntero a dónde te encuentras ahora; normalmente apunta a una rama (ref: refs/heads/main). Si cambias a un commit o tag concreto, HEAD apuntará directamente al commit: es el estado detached HEAD.

6. ¿Qué es detached HEAD y por qué es peligroso?

Es el estado en el que HEAD apunta a un commit y no a una rama, por ejemplo tras git switch --detach v1.0 o git checkout a1b2c3d. Puedes ver el código e incluso hacer commits, pero los commits nuevos no pertenecen a ninguna rama.

Si después cambias a otra rama, esos commits quedarán inalcanzables y con el tiempo el recolector de basura los eliminará. Para conservar el trabajo, crea una rama: git switch -c fix-from-detached. Si ya te has ido, el hash se encuentra en git reflog.

7. ¿En qué se diferencia git fetch de git pull?

git fetch descarga los commits nuevos y actualiza las ramas de seguimiento remoto como origin/main, pero no toca tus ramas locales ni tus archivos. git pull es fetch más integración: por defecto merge, y con la opción --rebase o el ajuste pull.rebase=true, rebase.

Los desarrolladores con experiencia suelen hacer fetch por separado, revisar git log HEAD..origin/main y solo entonces decidir cómo integrar los cambios.

8. ¿Cómo funciona .gitignore y por qué un archivo sigue con seguimiento aunque esté en él?

.gitignore define patrones de archivos que Git no debe proponer añadir: dependencias, builds, logs, configuraciones locales con secretos. Las reglas solo afectan a archivos sin seguimiento.

Si el archivo ya se había incluido en un commit, ignorarlo no tiene efecto. Hay que sacarlo del índice dejándolo en disco: git rm --cached config.local.php, y hacer commit de esa eliminación. Para comprobar qué regla se aplica sirve git check-ignore -v ruta.

Ramas, fusiones y conflictos

9. ¿Qué es un fast-forward merge?

Si la rama de destino no ha avanzado desde que se creó la rama, al fusionar Git simplemente mueve su puntero al último commit de la rama que se integra, sin crear un commit nuevo. El historial queda lineal.

La opción --no-ff obliga a crear un commit de merge incluso en ese caso: así en el historial se ve que un grupo de commits era una feature aparte. La opción --ff-only, al revés, solo permite fast-forward y se niega si hace falta un merge real.

10. ¿Cómo surge un conflicto de fusión y cómo se resuelve?

Un conflicto surge cuando en ambas ramas se han modificado las mismas líneas de un archivo (o el archivo se borró en una rama y se modificó en otra) y Git no puede decidir solo. Detiene la fusión y marca los puntos con <<<<<<<, =======, >>>>>>>.

git status                 # lista de archivos con conflictos
# editamos los archivos dejando la versión correcta
git add app.js
git commit                 # para merge; para rebase, git rebase --continue

Una buena respuesta incluye también la prevención: ramas pequeñas, hacer pull de la rama principal a menudo, acuerdos de formato. Y git merge --abort si hay que dar marcha atrás.

11. ¿En qué se diferencian merge y rebase?

merge une dos ramas creando un commit de merge con dos padres; los commits existentes no cambian y el historial refleja fielmente el trabajo en paralelo. rebase traslada los commits de tu rama encima de otra rama creando copias con hashes nuevos; el historial queda lineal.

La regla habitual: rebase para ordenar tu rama local antes de publicarla, merge para integrar en ramas compartidas. Hacer rebase de commits publicados sobre los que trabajan otros provoca duplicados y confusión.

12. ¿Qué es el rebase interactivo y para qué sirve?

git rebase -i HEAD~5 abre la lista de los cinco últimos commits, donde para cada uno eliges una acción: pick (mantener), reword (cambiar el mensaje), edit (detenerse y corregir), squash y fixup (fusionar con el anterior), drop (eliminar). Las líneas se pueden reordenar.

El caso típico: antes de un pull request, convertir «wip», «fix typo», «otro fix» en dos o tres commits con sentido. Una combinación práctica: git commit --fixup=<hash> y luego git rebase -i --autosquash.

13. ¿Qué hace un squash merge y cuándo se elige?

En un squash merge todos los commits de la rama se comprimen en un único commit en la rama de destino (git merge --squash o el botón de GitHub/GitLab). La rama principal recibe un commit por feature.

La ventaja es un historial de main limpio. El inconveniente es que se pierde el historial detallado de la feature y Git no considera fusionada la rama original, así que git branch -d se negará a borrarla sin -D.

14. ¿Qué es cherry-pick y cuándo tiene sentido?

git cherry-pick <hash> aplica los cambios de un commit a la rama actual creando un commit nuevo con el mismo contenido pero otro hash. El caso clásico es llevar la corrección de un bug de develop a la rama de release o de hotfix.

No conviene abusar: el mismo fix vive en dos commits y al fusionar las ramas más tarde pueden aparecer conflictos. La opción -x añade al mensaje una referencia al commit original.

Deshacer cambios y recuperación

15. ¿En qué se diferencian git reset --soft, --mixed y --hard?

Modo	Puntero de la rama	Índice	Directorio de trabajo
--soft	se mueve	no cambia	no cambia
--mixed (por defecto)	se mueve	se vacía	no cambia
--hard	se mueve	se vacía	se restablece, los cambios se pierden

git reset --soft HEAD~3 va bien para rehacer los tres últimos commits como uno solo. --hard es peligroso para los cambios sin commit: ni el reflog los recupera.

16. ¿En qué se diferencia git revert de git reset?

reset mueve el puntero de la rama hacia atrás, reescribiendo de hecho el historial. revert crea un commit nuevo que anula los cambios del indicado y no reescribe nada.

Por eso, para commits publicados en una rama compartida la respuesta correcta es revert: el historial de los compañeros no se rompe y la anulación queda visible en el log. Para un commit de merge hay que indicar el padre principal: git revert -m 1 <hash>.

17. ¿Cómo recuperar commits tras un git reset --hard accidental?

Con git reflog: guarda en local el historial de movimientos de HEAD y de las ramas (por defecto las entradas duran unos 90 días). Buscamos la entrada anterior al comando fallido y volvemos a ella:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Añadir el pago
git reset --hard 9f8e7d6

Una salvedad importante: el reflog solo salva lo que estaba en commits. Los cambios que nunca llegaron a un commit (ni al menos a un stash) no se pueden recuperar con Git.

18. ¿Cómo descartar los cambios de un archivo y sacarlo del índice?

Los comandos modernos son git restore app.js (devolver el archivo al estado del índice) y git restore --staged app.js (sacarlo del índice conservando los cambios). Antes se usaban git checkout -- app.js y git reset HEAD app.js, que siguen funcionando.

19. ¿Qué es git stash y qué trampas tiene?

git stash guarda temporalmente los cambios sin commit y limpia el directorio de trabajo, por ejemplo para pasar con urgencia a un hotfix. Se recuperan con git stash pop o apply.

Trampas: por defecto no guarda los archivos sin seguimiento (hace falta -u); con pop puede haber un conflicto y entonces la entrada no se elimina de la lista; y es fácil olvidarse del stash. Para trabajos largos es mejor un commit en una rama aparte.

Preguntas avanzadas y trabajo en equipo

20. ¿Cómo encontrar el commit que rompió una funcionalidad?

Con git bisect, una búsqueda binaria en el historial. Indicas un commit malo y otro bueno, y Git te lleva a la mitad del rango hasta encontrar al culpable en log2(N) pasos.

git bisect start
git bisect bad                 # la versión actual está rota
git bisect good v2.3.0         # aquí todo funcionaba
# probamos y respondemos good/bad hasta que Git señale el commit
git bisect reset

Si tienes un script de comprobación, el proceso se automatiza: git bisect run npm test.

21. ¿Por qué git push --force es peligroso y qué usar en su lugar?

--force sobrescribe la rama remota con tu versión, y los commits que tus compañeros ya habían subido desaparecen del servidor. Es más seguro git push --force-with-lease: solo sobrescribe la rama si en el servidor está en el estado que viste en tu último fetch.

El push forzado es normal en tu propia rama de feature tras un rebase; en main y otras ramas compartidas suele estar prohibido mediante la protección de ramas del servidor.

22. ¿Qué workflows de Git conoces?

GitHub Flow: una rama principal siempre lista para desplegar y ramas de feature cortas que se integran mediante pull request tras la revisión y el CI. Git Flow: ramas main y develop, más feature/*, release/* y hotfix/*; encaja en productos con releases versionadas. Trunk-based development: todos integran en trunk con mucha frecuencia y lo que está a medias se oculta tras feature flags.

Una respuesta sólida justifica la elección: para un servicio web con despliegue continuo, Git Flow suele ser excesivo; para una librería con soporte de varias versiones, está justificado.

23. ¿Qué es un pull request y qué se revisa en él?

Un pull request (en GitLab, merge request) es una solicitud para fusionar una rama que pasa por revisión de código y comprobaciones automáticas de CI antes de integrarse. Es una función de la plataforma (GitHub, GitLab, Bitbucket), no del propio Git.

Un buen PR es pequeño, resuelve una sola tarea, tiene una descripción clara y está vinculado a la tarea del tracker. El revisor comprueba la corrección, la legibilidad, los tests y que no se hayan colado archivos sobrantes o secretos.

24. ¿Qué reglas sigues para escribir un buen mensaje de commit?

Un título corto (hasta 50–72 caracteres) en imperativo, como «Añadir validación del email», luego una línea en blanco y un cuerpo que explique el «por qué», no el «qué» (lo que cambió ya se ve en el diff). Muchos equipos usan Conventional Commits: feat:, fix:, docs:, refactor:.

Estos mensajes permiten generar el changelog, encontrar rápido lo que buscas con git log --grep y entender los motivos de los cambios años después.

25. ¿Qué harías si subes por error una contraseña al repositorio?

Lo primero: revocar y regenerar el secreto. Ya está comprometido aunque lo borres un minuto después (clones, forks, cachés). Después, dejar de seguir el archivo, añadirlo a .gitignore y, si hace falta, limpiar el historial con herramientas como git filter-repo, seguido de un force push y un aviso al equipo.

Aquí el entrevistador comprueba las prioridades: el candidato que empieza reescribiendo el historial y se olvida de rotar la clave responde mal.

Cómo prepararse para las preguntas de Git

Lo más fiable no es memorizar respuestas, sino reproducir cada escenario a mano en un repositorio de prueba: crear un conflicto y resolverlo, hacer reset --hard y recuperarte con el reflog, comprimir commits con rebase interactivo. En las entrevistas de Git a menudo ponen un ejercicio práctico o piden dibujar el grafo de commits antes y después de un comando; si lo has hecho tú mismo, el dibujo sale solo.

También es útil hacer un pequeño test de Git para autoevaluarte: intenta responder sin ayuda qué pasará con el historial tras git rebase main o git revert HEAD. Si respondes con seguridad a «qué cambia en las tres áreas», tienes la base.

Conclusión

Una entrevista de Git casi siempre gira en torno a tres temas: el modelo de datos (commits, ramas, HEAD, índice), la integración de cambios (merge, rebase, conflictos, fetch y pull) y cómo deshacer con seguridad (reset, revert, reflog). Añade la comprensión de los workflows de equipo y los pull requests y cubrirás la inmensa mayoría de las preguntas. Todos estos escenarios, incluido el trabajo en equipo y las herramientas avanzadas, se practican en el curso de Git.