Capitulo 05
Git y Control de Versiones para Analistas
Transversal a toda oferta tecnica: barato de cerrar, caro de no tenerlo
El flujo basico de Git, branching, Pull Requests y resolucion de conflictos en la practica — la base que se espera en cualquier rol tecnico.
Deloitte lo pidio para un rol de “Data Analyst” — no solo para desarrolladores. Si hoy no tienes un flujo comodo con branches, Pull Requests y resolucion de conflictos, es el gap mas rapido de cerrar de todo este curso.
5.1 El flujo basico
git init # inicializa un repositorio
git add archivo.sql # agrega un archivo al staging area
git commit -m "Agrega query de ventas mensuales"
git remote add origin <url> # conecta con un repositorio remoto (GitHub)
git push -u origin main # sube los commits al remoto
git pull # trae cambios nuevos del remoto5.2 Branching: trabajar en paralelo sin pisarse
Feature Branch
M15Rama de Git creada para desarrollar una funcionalidad o cambio especifico de forma aislada del branch principal, evitando que trabajo incompleto rompa lo que ya funciona.
git checkout -b feature/reporte-mensual # crea y cambia a un nuevo branch
# ... trabajas, haces commits ...
git push -u origin feature/reporte-mensual
# Se abre un Pull Request en GitHub/GitLab desde ese branch hacia mainTrabajar directo sobre main funciona solo mientras trabajas solo y nunca cometes un error a medio terminar. En cuanto hay mas de una persona (o tú mismo revisando el trabajo de otro dia), un cambio incompleto en main bloquea a todos los demas. Un feature branch aisla tu trabajo en progreso hasta que este listo y revisado — el costo de crear un branch es un comando; el costo de NO usarlo es un main roto para todo el equipo.
Deloitte pidio Git explicitamente para un rol de “Data Analyst” en la muestra de mercado — no un rol de desarrollo. En la practica, esto suele significar: cada script SQL/Python de reporting vive en un repo, cada cambio pasa por un branch + Pull Request antes de tocar el reporte que usa el negocio, y el historial de commits sirve como bitacora de “por que cambio este numero” cuando alguien pregunta 6 meses despues.
5.3 Merge vs Rebase
Merge vs Rebase
M15Merge integra los cambios de un branch a otro preservando el historial completo con un commit de fusion. Rebase reescribe el historial del branch, aplicando sus commits como si hubieran partido desde el estado actual del branch destino — produce un historial lineal, pero reescribe commits ya existentes.
| Concepto | Descripcion |
|---|---|
| merge | Preserva el historial exacto de ambos branches, incluyendo un commit de fusion. Mas seguro para branches compartidos por varias personas. |
| rebase | Reescribe el historial para que parezca lineal, sin commit de fusion. Nunca hacer rebase de un branch que otros ya tienen descargado. |
5.4 Pull Requests: donde pasa la revision de codigo
Pull Request (PR)
M15Solicitud formal para fusionar los cambios de un branch a otro (tipicamente hacia main), que habilita revision de codigo, comentarios y discusion antes de aceptar el cambio.
Un buen PR: tiene un titulo y descripcion claros de QUE cambia y POR QUE, es pequeño y enfocado (mas facil de revisar), y pasa cualquier chequeo automatico configurado (linting, tests) antes de poder fusionarse.
Un PR que cambia la logica de un query de comisiones (“ahora excluir devoluciones del calculo”) deberia mostrar en su descripcion QUE regla de negocio cambio y POR QUE (ej. “pedido de Finanzas, ticket JIRA-123”), no solo el diff del SQL. Eso permite que quien revisa juzgue si la regla de negocio es correcta, no solo si el SQL es sintacticamente valido.
5.5 Resolver un conflicto de merge, en la practica
Un conflicto de merge NO es un error — es Git avisandote que dos cambios tocaron la misma linea y necesita que decidas cual (o ambos) conservar. Git marca el archivo con marcadores <<<<<<< / ======= / >>>>>>>: editas el archivo para dejarlo como deberia quedar, eliminas los marcadores, y haces git add + git commit para cerrar el conflicto.
<<<<<<< HEAD
SELECT cliente_id, SUM(monto) AS total FROM ventas GROUP BY cliente_id;
=======
SELECT cliente_id, region, SUM(monto) AS total FROM ventas GROUP BY cliente_id, region;
>>>>>>> feature/agregar-regionAqui, la decision correcta suele ser quedarse con la version que agrega region (mas completa) — pero eso depende del contexto de negocio, que solo tú sabes al mirar el conflicto.
5.6 .gitignore y mensajes de commit
Un .gitignore evita subir archivos que no deberian versionarse: credenciales, archivos temporales, entornos virtuales, salidas de build. Un buen mensaje de commit describe el “por que”, no repite el diff: "Corrige duplicados en carga incremental de ventas" es mejor que "fix".
5.7 Recursos
5.8 Preguntas de entrevista
Q: Dos personas editaron el mismo archivo y ahora tienes un conflicto de merge. ¿Que haces?
Abro el archivo con conflicto, identifico los bloques marcados por Git (<<<<<<<, =======, >>>>>>>), decido con criterio de negocio (no solo tecnico) que version conservar o si hay que combinar ambas, elimino los marcadores, y hago git add + git commit para cerrar el conflicto. Si no estoy seguro del contexto del otro cambio, hablo con quien lo hizo antes de decidir.
🪤 Responder 'uso git merge --abort y descarto' como solucion general — eso evita el conflicto, no lo resuelve.- Crea un repositorio local con un archivo de texto simple.
- Crea dos branches distintos que editen la MISMA linea de ese archivo de formas diferentes.
- Intenta hacer merge de ambos hacia main y deja que Git marque el conflicto.
- Resuelvelo manualmente y documenta en un archivo aparte cada paso que seguiste.