Git

Llevas tres archivos editados en una rama de feature, sin nada confirmado, cuando un compañero te avisa de un null pointer en producción. El movimiento habitual es hacer git stash, cambiar a main, arreglarlo, hacer push, y luego git stash pop con la esperanza de que nada de tu feature a medias dependiera de los archivos que acabas de tocar. git worktree evita todo ese baile. Hace checkout de la rama del hotfix en una segunda carpeta, junto a la de tu feature, y ambas comparten el mismo repositorio. ...

Ejecuta git reset --hard sobre un commit que tu equipo ya bajó y acabas de dejar tu historial en desacuerdo con el suyo. Ejecuta git revert sobre un typo que no has subido y añades un commit innecesario al log. Git tiene cuatro comandos para deshacer cambios, restore, reset, commit --amend y revert, y no son intercambiables. Elige el equivocado y el resultado es que no pasa nada, o pasa mucho más de lo que querías. ...

La suite de pruebas lleva tres semanas en verde. Hoy npm test falla en una aserción que no tiene nada que ver con lo que acabas de cambiar, y git log v1.4.0..HEAD muestra 340 commits de cuatro personas desde la última release que alguien confirmó que funcionaba. Leer cada diff te cuesta un día entero. Hacer checkout de commits al azar es más rápido, pero sigue sin ser un plan. ...

Haces pull del último main y Git se detiene con CONFLICT (content): Merge conflict in checkout.js. Resuelves el conflicto y el log muestra ahora un commit llamado Merge branch 'main' into feature/checkout, sentado encima de los tres commits que en realidad escribiste tú. Cuatro commits, un solo cambio real. Un compañero que lea ese historial el mes que viene no puede saber cuál es cuál. git merge y git rebase responden a la misma pregunta: cómo pongo mi rama al día con los cambios hechos en otro sitio. Dejan rastros muy distintos, y elegir el equivocado en una rama compartida causa daño real. ...