Respuestas modelo
Consulta aquí las respuestas correctas y explicaciones de las autoevaluaciones y los tests del manual. Ideal para repasar antes de un test o aclarar dudas.
1.08 · Buenas Prácticas, Git Básico y Clean Code Inicial
17 preguntas con respuesta en este tema.
🎯 Autoevaluación (4)
¿Qué es Git?
- A. Un editor de código
- B. Un sistema de control de versiones distribuido ✓ CORRECTA
- C. Un lenguaje de programación
- D. Un framework
Git es VCS (Version Control System) distribuido. Permite historial, ramas, colaboración. Creado por Linus Torvalds en 2005.
¿Qué comando inicia un repositorio Git local?
- A. git start
- B. git init ✓ CORRECTA
- C. git create
- D. git new
`git init` crea un nuevo repositorio Git en el directorio actual (crea la carpeta .git).
¿Cuál es la diferencia entre `git pull` y `git fetch`?
- A. Son lo mismo
- B. fetch descarga cambios, pull descarga y fusiona ✓ CORRECTA
- C. pull es más rápido
- D. fetch es para GitHub
fetch: solo descarga. pull: descarga + merge. Pull = fetch + merge en un solo paso.
¿Qué significa "Clean Code"?
- A. Código sin comentarios
- B. Código legible, mantenible y con buenas prácticas ✓ CORRECTA
- C. Código compilado
- D. Código sin errores
Clean Code (Robert C. Martin): nombres claros, funciones cortas, sin duplicación, comentarios útiles, formateo consistente.
📝 Test · Sección A · Opción múltiple (10)
¿Qué es Git?
- A. Un lenguaje
- B. Un sistema de control de versiones distribuido ✓ CORRECTA
- C. Un editor
- D. Una base de datos
Git: VCS distribuido creado por Linus Torvalds en 2005.
¿Qué comando inicia un repositorio Git?
- A. git start
- B. git init ✓ CORRECTA
- C. git create
- D. git new
git init crea un nuevo repo en el directorio actual.
¿Qué hace git add?
- A. Confirma cambios
- B. Agrega archivos al staging area ✓ CORRECTA
- C. Sube al remoto
- D. Crea rama
git add <archivos> los pone en staging para el próximo commit.
¿Qué hace git commit?
- A. Sube al servidor
- B. Guarda los cambios del staging en el historial local ✓ CORRECTA
- C. Borra archivos
- D. Crea rama
git commit -m "mensaje" crea un commit en el historial local.
¿Qué hace git push?
- A. Borra
- B. Sube los commits locales al repositorio remoto ✓ CORRECTA
- C. Hace commit
- D. Crea archivo
git push envía los commits locales al servidor remoto (GitHub, GitLab, etc.).
¿Qué es una rama (branch) en Git?
- A. Una copia del proyecto
- B. Un apuntador a un commit que avanza con nuevos commits ✓ CORRECTA
- C. Un archivo
- D. Un commit
Una rama es un apuntador móvil a commits. main, develop, feature/x son comunes.
¿Qué hace git pull?
- A. Borra el remoto
- B. Descarga y fusiona cambios del remoto al local ✓ CORRECTA
- C. Crea commit
- D. Borra rama
git pull = git fetch + git merge.
¿Cuál es la diferencia entre git merge y git rebase?
- A. Son iguales
- B. merge preserva historia, rebase la reescribe linealmente ✓ CORRECTA
- C. rebase es más rápido
- D. merge borra commits
merge: une con merge commit. rebase: reaplica commits linealmente.
¿Qué es clean code según Robert C. Martin?
- A. Sin comentarios
- B. Código legible, mantenible, con buenas prácticas ✓ CORRECTA
- C. Solo compila
- D. Sin tests
Clean Code: nombres claros, funciones cortas, sin duplicación, etc.
¿Por qué son importantes los commits pequeños y frecuentes?
- A. Ocupan menos espacio
- B. Facilitan el code review, revert y el seguimiento de bugs ✓ CORRECTA
- C. Son más rápidos
- D. No son importantes
Commits pequeños son más fáciles de revisar, revertir y entender.
✍️ Test · Sección B · Preguntas abiertas (3)
Explica el flujo de Git: working directory, staging area, repository. ¿Qué comandos mueven entre estas zonas?
Working directory: archivos en disco. Staging area: archivos preparados para commit. Repository: historial de commits. Working → Staging: git add. Staging → Repository: git commit. Repository → Working: git checkout/restore.
¿Qué es un buen mensaje de commit? Da un ejemplo bueno y uno malo.
Bueno: "Fix: corrige overflow en cálculo de promedio móvil". Específico, menciona qué y por qué. Malo: "fix" o "cambios" o "wip". Son vagos, no dicen nada. Reglas: línea corta (<72 chars), imperativo, explica el por qué si es complejo.
¿Por qué es importante hacer commits pequeños y frecuentes en lugar de uno grande al final?
Commits pequeños: más fáciles de revisar, revertir, y entender el progreso. Permiten integrar trabajo sin conflictos grandes. Si algo se rompe, sabes exactamente qué cambio lo causó. Facilitan code review.
📝 ¿Listo para evaluarte?
Regístrate o inicia sesión para tomar la autoevaluación o el test de este tema y registrar tu puntaje.