🛠️ Entornos de desarrollo

1. En Git, cada clon completo de un repositorio contiene toda la historia del proyecto, no solo la versión más reciente, lo que permite trabajar sin conexión al servidor central. ¿Cómo se clasifica este tipo de sistema de control de versiones?

1. Sistema de control de versiones centralizado
2. Sistema de control de versiones distribuido
3. Sistema de control de versiones local
4. Sistema de control de versiones federado

Git es un sistema de control de versiones distribuido (DVCS): cada copia local contiene la historia completa del proyecto. En un sistema centralizado, como SVN, solo el servidor conserva la historia completa. (Scott Chacon y Ben Straub, "Pro Git" (2ª ed.), cap. 1 "About Version Control", git-scm.com/book)

2. Dentro del flujo de trabajo local de Git, un archivo que fue editado y guardado en el directorio de trabajo, pero que aún no se ha agregado al área de preparación (staging area), se encuentra en el estado:

1. Preparado (staged)
2. Confirmado (committed)
3. Rastreado (tracked)
4. Modificado (modified)

Los tres estados principales del flujo de Git son modified, staged y committed; un archivo editado pero no agregado con git add permanece en estado modified. "Tracked" describe si Git conoce el archivo, no en cuál de los tres estados se encuentra. ("Pro Git" (2ª ed.), cap. 1 "Git Basics - The Three States", git-scm.com/book)

3. Un desarrollador modificó dos archivos, pero solo quiere incluir uno de ellos en el próximo commit. ¿Qué secuencia de comandos logra ese objetivo?

1. git add archivo1.js, después git commit -m "mensaje"
2. git commit -a -m "mensaje", después git add archivo1.js
3. git add -A, después git commit -m "mensaje"
4. git commit -m "mensaje", después git add archivo1.js

git add archivo1.js prepara solo ese archivo y git commit confirma únicamente lo que está en el área de preparación; git commit -a o git add -A incluirían ambos archivos modificados, incumpliendo el objetivo. ("Pro Git" (2ª ed.), cap. 2 "Recording Changes to the Repository", git-scm.com/book)

4. Git identifica cada objeto de su base de datos (commit, árbol, blob) mediante una suma de verificación representada como una cadena hexadecimal de 40 caracteres. ¿Qué algoritmo hash utiliza Git para calcularla?

1. MD5
2. CRC32
3. SHA-1
4. SHA-256

Git calcula la suma de verificación de cada objeto con SHA-1, expresada como 40 caracteres hexadecimales. SHA-256 es un algoritmo alterno más reciente en Git, pero no el documentado como estándar en Pro Git; MD5 y CRC32 no son el algoritmo que usa Git para este fin. ("Pro Git" (2ª ed.), cap. 1 y cap. 10 "Git Internals - Git Objects", git-scm.com/book)

5. En Git existe un apuntador que indica en qué rama o commit se encuentra actualmente el usuario, y que normalmente se mueve al último commit de la rama activa conforme se generan nuevos commits. ¿Cómo se llama esa referencia?

1. ORIG_HEAD
2. HEAD
3. MERGE_HEAD
4. FETCH_HEAD

HEAD es el apuntador simbólico a la rama activa. ORIG_HEAD, MERGE_HEAD y FETCH_HEAD son referencias especiales que Git crea temporalmente durante operaciones como rebase, merge o fetch, no el apuntador general de la posición actual. ("Pro Git" (2ª ed.), cap. 3 "Branches in a Nutshell", git-scm.com/book)

6. Conceptualmente, ¿qué es una rama (branch) en Git?

1. Una copia física completa de todos los archivos del repositorio
2. Un directorio separado con una versión distinta del proyecto
3. Un archivo que registra los cambios pendientes de fusionar
4. Un apuntador móvil y ligero hacia un commit específico

Una rama en Git es un apuntador ligero que se desplaza automáticamente al nuevo commit conforme se confirma trabajo, por lo que crear o cambiar de rama es una operación rápida y no implica copiar archivos físicamente. ("Pro Git" (2ª ed.), cap. 3 "Git Branching - Branches in a Nutshell", git-scm.com/book)

7. Cuando la rama receptora no tiene commits nuevos desde el punto en que se creó la rama que se va a integrar, Git puede resolver la fusión moviendo simplemente el apuntador de la rama hacia adelante, sin crear un commit de fusión adicional. ¿Cómo se llama este tipo de fusión?

1. Fusión de avance rápido (fast-forward)
2. Fusión de tres vías (three-way merge)
3. Fusión recursiva (recursive merge)
4. Fusión squash (squash merge)

Cuando no hay divergencia entre las ramas, Git resuelve la fusión adelantando el apuntador (fast-forward) sin generar un commit nuevo; la fusión de tres vías se usa cuando ambas ramas sí divergieron y requiere un commit de fusión adicional. ("Pro Git" (2ª ed.), cap. 3 "Basic Branching and Merging", git-scm.com/book)

8. Dos desarrolladores modifican la misma línea del mismo archivo en ramas distintas. Al intentar integrar ambas ramas con git merge, Git no puede decidir automáticamente cuál cambio conservar. ¿Qué ocurre en este caso?

1. Git conserva automáticamente el cambio de la rama que se integra (la rama entrante)
2. Git elimina ambos cambios y deja la línea vacía para que el usuario decida
3. Git detiene la fusión y marca el archivo con un conflicto que debe resolverse manualmente
4. Git conserva automáticamente el cambio de la rama receptora (la rama actual)

Ante cambios incompatibles en las mismas líneas, Git detiene la fusión y marca el archivo en conflicto para que el desarrollador decida manualmente; no existe una resolución automática que favorezca a una rama ni un borrado del contenido. ("Pro Git" (2ª ed.), cap. 3 "Basic Merge Conflicts", git-scm.com/book)

9. Durante una fusión, Git marca un conflicto en el archivo config.py con las líneas <<<<<<<, ======= y >>>>>>>. El desarrollador edita el archivo, decide qué contenido conservar y elimina esas líneas de marcado. ¿Qué debe hacer a continuación para completar la fusión?

1. Ejecutar únicamente git commit, ya que Git detecta de forma automática que el archivo ya fue resuelto
2. Ejecutar git add sobre el archivo resuelto y después git commit para finalizar la fusión
3. Ejecutar git merge --continue sin haber modificado el índice, pues el archivo se registra solo
4. Descartar el archivo con git checkout --ours y repetir la fusión completa desde el inicio

Tras resolver un conflicto manualmente, es necesario volver a preparar el archivo con git add antes de confirmar la fusión con git commit; Git no detecta por sí solo que el conflicto quedó resuelto con solo quitar los marcadores. ("Pro Git" (2ª ed.), cap. 3 "Basic Merge Conflicts", git-scm.com/book)

10. Un equipo ya publicó (push) una serie de commits de una rama compartida a un repositorio remoto que usan varios integrantes. ¿Qué recomienda la práctica estándar de Git respecto a usar git rebase sobre esos commits ya publicados?

1. Rebasarlos de inmediato para mantener un historial lineal antes de que otros los descarguen
2. Rebasarlos solo si se usa la bandera --force al hacer push posterior
3. Rebasarlos únicamente cuando el equipo tiene menos de tres integrantes
4. Evitar rebasarlos, pues reescribe su historia y genera inconsistencias para quienes ya los tienen

La "regla de oro" del rebase es no reescribir commits ya compartidos en un repositorio público, porque reescribe la historia y provoca conflictos para quienes ya basaron trabajo sobre ellos; forzar el push no elimina ese riesgo. ("Pro Git" (2ª ed.), cap. 3 "Rebasing - The Perils of Rebasing", git-scm.com/book)

11. A diferencia de git merge, que en su caso crea un nuevo commit de fusión con dos padres, git rebase integra los cambios de una rama de la siguiente manera:

1. Reaplicando los commits de una rama, uno por uno, sobre la punta de otra rama base
2. Copiando físicamente el directorio de trabajo completo de la otra rama
3. Combinando ambos historiales en un único commit sin conservar su orden cronológico
4. Eliminando los commits de la rama base antes de aplicar los nuevos

git rebase toma los commits de una rama y los reaplica secuencialmente sobre otra base, generando un historial lineal, en lugar de crear un commit de fusión con dos padres como hace git merge. ("Pro Git" (2ª ed.), cap. 3 "Rebasing", git-scm.com/book)

12. De las siguientes afirmaciones sobre el área de preparación (staging area) de Git, ¿cuál NO es correcta?

1. Contiene la instantánea que se incluirá en el siguiente commit
2. Se actualiza mediante la ejecución del comando git add
3. Sustituye por completo la necesidad de confirmar (commit) los cambios
4. Permite construir un commit seleccionando solo parte de los cambios

El área de preparación no sustituye al commit: solo git commit guarda los cambios de forma permanente en la historia del repositorio; el staging area únicamente arma la instantánea que se confirmará. ("Pro Git" (2ª ed.), cap. 2 "Recording Changes to the Repository", git-scm.com/book)

13. Según la práctica de Integración Continua (CI) descrita por Martin Fowler, ¿con qué frecuencia mínima se espera que cada integrante de un equipo integre su trabajo con el de los demás?

1. Al menos una vez por semana
2. Al menos una vez al día
3. Al menos una vez por sprint
4. Al menos una vez al mes

Fowler describe que en Integración Continua cada persona típicamente integra su trabajo al menos una vez al día, generando múltiples integraciones diarias verificadas por una compilación automática. (Martin Fowler, "Continuous Integration" (rev. 2006), martinfowler.com)

14. Un equipo permite que cada integrante trabaje en su propia rama durante varias semanas antes de integrar su código con el resto, sin ejecutar compilaciones automáticas intermedias. De acuerdo con la práctica de Integración Continua, esta forma de trabajar:

1. Es equivalente a CI, siempre que al final se ejecute una sola compilación exitosa
2. Cumple con CI, porque cada rama se integra eventualmente sin importar la frecuencia
3. Mejora la práctica de CI, al reducir el número de compilaciones necesarias
4. Contradice la práctica de CI, que requiere integraciones frecuentes verificadas por una compilación automática

Integrar cada varias semanas sin compilaciones automáticas frecuentes es contrario a la Integración Continua, que exige integraciones frecuentes (al menos diarias) verificadas mediante una compilación automatizada. (Martin Fowler, "Continuous Integration", martinfowler.com)

15. En Entrega Continua (Continuous Delivery), el software se mantiene en todo momento en un estado desplegable a producción. ¿Qué distingue a esta práctica del Despliegue Continuo (Continuous Deployment)?

1. En Entrega Continua el paso final a producción es una decisión manual; en Despliegue Continuo ocurre automáticamente
2. En Entrega Continua el paso final a producción es automático; en Despliegue Continuo requiere aprobación manual
3. Entrega Continua no incluye pruebas automatizadas, mientras que Despliegue Continuo sí las incluye
4. Entrega Continua aplica solo a aplicaciones móviles, mientras que Despliegue Continuo aplica a aplicaciones web

Humble y Farley distinguen que en Continuous Delivery el software siempre queda listo para desplegarse, pero el paso a producción se conserva como decisión manual de negocio; en Continuous Deployment ese último paso se automatiza. (Jez Humble y David Farley, "Continuous Delivery" (2010); Martin Fowler, martinfowler.com)

16. Un producto se encuentra en la versión 0.7.2, correspondiente a la etapa de desarrollo inicial según el Versionado Semántico. El equipo introduce un cambio que rompe la compatibilidad con versiones anteriores. Según la especificación, ¿qué se espera en este caso?

1. La versión debe avanzar directamente a 1.0.0, igual que en cualquier otra etapa del proyecto
2. La versión debe retroceder a 0.0.1, pues un cambio incompatible reinicia el conteo
3. La versión puede avanzar dentro del rango 0.y.z, ya que durante el desarrollo inicial la API puede cambiar en cualquier momento
4. La versión permanece igual, porque antes de 1.0.0 los cambios incompatibles no se reflejan en el número de versión

El Versionado Semántico señala que la versión mayor cero (0.y.z) corresponde al desarrollo inicial, etapa en la que la API puede cambiar en cualquier momento sin que sea obligatorio saltar a 1.0.0 por cada cambio incompatible. (Semantic Versioning 2.0.0, punto 4, semver.org)

17. A diferencia de una máquina virtual, que incluye un sistema operativo invitado completo ejecutado sobre un hipervisor, un contenedor:

1. Requiere su propio hipervisor dedicado independiente del anfitrión
2. Comparte el kernel del sistema operativo anfitrión y aísla solo los procesos de la aplicación
3. Incluye siempre una copia completa de un sistema operativo invitado
4. Ejecuta el código directamente sobre el hardware sin ningún sistema operativo

El contenedor comparte el kernel del sistema operativo anfitrión y solo aísla los procesos de la aplicación, lo que lo hace más ligero que una máquina virtual, la cual sí requiere un sistema operativo invitado completo. (Documentación oficial de Docker, "What is a container?", docs.docker.com/get-started)

18. En la terminología de Docker, ¿cómo se llama la plantilla de solo lectura que contiene las instrucciones necesarias para crear un contenedor ejecutable?

1. Contenedor
2. Volumen
3. Registro (registry)
4. Imagen

La imagen es la plantilla de solo lectura; el contenedor es la instancia en ejecución creada a partir de ella. El volumen sirve para persistir datos y el registro para almacenar y distribuir imágenes, funciones distintas a la de la imagen. (Documentación oficial de Docker, "Docker overview / Docker objects", docs.docker.com)

19. Un Dockerfile inicia con la línea ARG VERSION=1.0, seguida de una instrucción FROM que utiliza esa variable en el nombre de la imagen base. ¿Esta estructura respeta la regla sobre cuál debe ser la primera instrucción efectiva de un Dockerfile?

1. Sí, porque ARG puede preceder a FROM y aun así FROM se considera la primera instrucción efectiva
2. No, porque ninguna instrucción puede aparecer antes de FROM bajo ninguna circunstancia
3. Sí, porque cualquier instrucción puede colocarse antes de FROM sin restricción alguna
4. No, porque FROM debe declararse antes que cualquier variable ARG usada en la imagen base

Docker permite que una o más instrucciones ARG aparezcan antes de FROM, por ejemplo para parametrizar la imagen base; descontando comentarios y esos ARG previos, FROM sigue siendo la primera instrucción efectiva del Dockerfile. (Documentación oficial de Docker, "Dockerfile reference - FROM", docs.docker.com/reference/dockerfile)

20. En Kubernetes, ¿cómo se llama la unidad de cómputo desplegable más pequeña que se puede crear y administrar, la cual agrupa uno o más contenedores que comparten almacenamiento y red?

1. Nodo (Node)
2. Servicio (Service)
3. Pod
4. Namespace

El Pod es la unidad desplegable más pequeña en Kubernetes. El Nodo es la máquina que ejecuta Pods, el Service expone un conjunto de Pods en la red, y el Namespace es una partición lógica del clúster. (Documentación oficial de Kubernetes, "Concepts - Workloads - Pods", kubernetes.io/docs)

21. Un clúster de Kubernetes se compone, a alto nivel, de un conjunto de componentes que gestionan el estado deseado del clúster y de otro conjunto que ejecuta las cargas de trabajo. ¿Cómo se denominan, respectivamente?

1. Servidor maestro (master server) y contenedores huérfanos
2. Plano de control (control plane) y nodos de trabajo (worker nodes)
3. Registro central (registry) y nodos de trabajo (worker nodes)
4. Plano de control (control plane) y volúmenes persistentes

El clúster se compone del plano de control, que administra el estado deseado, y de los nodos de trabajo, que ejecutan los Pods; el registro y los volúmenes persistentes cumplen otras funciones dentro del ecosistema de contenedores. (Documentación oficial de Kubernetes, "Concepts - Overview - Cluster Architecture", kubernetes.io/docs)

22. Un equipo necesita levantar, con un solo comando, una aplicación compuesta por un servicio web, una base de datos y una caché, definiendo la configuración de los tres en un solo archivo declarativo. ¿Qué herramienta y formato de archivo son adecuados para este propósito?

1. Dockerfile, con un archivo en formato JSON
2. kubectl, con un archivo en formato XML
3. Docker Compose, con un archivo en formato INI
4. Docker Compose, con un archivo en formato YAML

Docker Compose permite definir y ejecutar aplicaciones multicontenedor mediante un archivo declarativo en formato YAML (docker-compose.yml o compose.yaml); un Dockerfile construye una sola imagen y no orquesta múltiples servicios. (Documentación oficial de Docker, "Docker Compose overview", docs.docker.com/compose)

23. El estándar de Versionado Semántico (Semantic Versioning) define un número de versión compuesto por tres componentes numéricos separados por puntos. ¿Cuál es el orden correcto de esos componentes?

1. MAJOR.MINOR.PATCH
2. PATCH.MINOR.MAJOR
3. MINOR.MAJOR.PATCH
4. MAJOR.PATCH.MINOR

El formato definido en Semantic Versioning 2.0.0 es MAJOR.MINOR.PATCH, donde cada componente se incrementa según un tipo específico de cambio en la API. (Semantic Versioning 2.0.0, punto 2, semver.org)

24. Un producto de software se encuentra en la versión 2.4.1. El equipo corrige un error interno sin agregar funcionalidad ni romper compatibilidad con versiones anteriores. Según el Versionado Semántico, ¿cuál debe ser la siguiente versión publicada?

1. 2.5.0
2. 3.0.0
3. 2.4.2
4. 2.4.0

Una corrección de errores compatible hacia atrás incrementa únicamente el componente PATCH, por lo que 2.4.1 pasa a 2.4.2; incrementar MINOR o MAJOR correspondería a nueva funcionalidad o a cambios incompatibles, que no ocurrieron aquí. (Semantic Versioning 2.0.0, puntos 6 y 8, semver.org)

25. Un producto se encuentra en la versión 1.9.5. El equipo agrega una función nueva que además elimina un parámetro existente de la API pública, por lo que el código cliente existente deja de funcionar sin modificaciones. Según el Versionado Semántico, ¿cuál debe ser la siguiente versión?

1. 1.10.0
2. 2.0.0
3. 1.9.6
4. 1.10.5

Aunque se agregó una función nueva, el cambio también rompe la compatibilidad de la API pública, por lo que debe incrementarse MAJOR y reiniciarse MINOR y PATCH a 0, resultando en 2.0.0; incrementar solo MINOR ignoraría la incompatibilidad introducida. (Semantic Versioning 2.0.0, puntos 6, 7 y 8, semver.org)

26. Respecto a los incrementos definidos por el Versionado Semántico (MAJOR.MINOR.PATCH), ¿cuál de las siguientes asociaciones NO es correcta?

1. Se incrementa MAJOR ante cambios incompatibles en la API
2. Se incrementa MINOR al añadir funcionalidad compatible hacia atrás
3. Se incrementa PATCH al corregir errores de manera compatible hacia atrás
4. Se incrementa PATCH al añadir una función nueva compatible con versiones anteriores

Añadir una función nueva compatible incrementa MINOR, no PATCH; PATCH se reserva para correcciones de errores compatibles hacia atrás, tal como indican correctamente las demás opciones. (Semantic Versioning 2.0.0, puntos 6, 7 y 8, semver.org)

27. Un equipo de desarrollo evalúa por qué Git permite a cada integrante seguir realizando confirmaciones (commits) aunque se pierda temporalmente la conexión a la red corporativa. ¿Cuál es la razón principal, según el modelo de Git?

1. Git es un sistema de control de versiones distribuido: cada clon del repositorio contiene la historia completa del proyecto, no solo la última versión.
2. Git es un sistema centralizado que guarda una copia en caché local temporal mientras se restablece la conexión con el servidor.
3. Git sincroniza automáticamente los cambios mediante un servidor intermediario que replica solo los archivos modificados.
4. Git requiere un servidor central para calcular las sumas de verificación de cada confirmación antes de guardarla localmente.

Git es un sistema de control de versiones distribuido (DVCS): cada clon contiene la historia completa, por lo que se puede confirmar cambios sin conexión al repositorio remoto; los sistemas centralizados sí dependen de un servidor central para casi toda operación. (Scott Chacon y Ben Straub, "Pro Git" (2ª ed.), cap. 1 "About Version Control", git-scm.com/book)

28. Dentro del flujo de trabajo local de Git, un archivo que ya fue editado pero todavía no se agregó al área de preparación (staging area) se encuentra en, ¿cuál de los siguientes estados?

1. Preparado (staged)
2. Modificado (modified)
3. Confirmado (committed)
4. Rastreado sin cambios (unmodified)

Pro Git define tres estados de un archivo (modificado, preparado y confirmado); un archivo editado pero no agregado con git add permanece en estado modificado. ("Pro Git" (2ª ed.), cap. 1 "The Three States", git-scm.com/book)

29. Una programadora edita dos archivos de un mismo requerimiento, pero solo quiere incluir uno de ellos en la próxima confirmación. ¿Qué secuencia de acciones es correcta para lograrlo en Git?

1. Ejecutar git commit directamente sobre el archivo deseado sin usar git add, ya que git commit selecciona los archivos de forma automática.
2. Ejecutar git add sobre ambos archivos y luego retirar del commit el que no se desea mediante git branch.
3. Ejecutar git add únicamente sobre el archivo deseado y después git commit, dejando el otro archivo modificado sin preparar.
4. Ejecutar git push del archivo deseado para preparar la instantánea antes de confirmarla con git commit.

git add agrega al área de preparación solo los archivos indicados, y git commit confirma la instantánea preparada; el otro archivo permanece modificado sin ser incluido en la confirmación. ("Pro Git" (2ª ed.), cap. 2 "Recording Changes to the Repository", git-scm.com/book)

30. Git identifica cada commit, árbol y blob mediante una suma de verificación calculada con un algoritmo hash, representada como una cadena hexadecimal de 40 caracteres. ¿Cuál es ese algoritmo?

1. MD5
2. CRC32
3. SHA-256
4. SHA-1

Git usa SHA-1 (cadena hexadecimal de 40 caracteres) para identificar sus objetos internos; MD5 y CRC32 no son el algoritmo usado con este fin, y SHA-256 solo existe como modo opcional en versiones recientes, no como el mecanismo histórico documentado. ("Pro Git" (2ª ed.), cap. 1 y cap. 10 "Git Objects", git-scm.com/book)

31. En un repositorio Git, HEAD generalmente apunta a la referencia de la rama activa, la cual a su vez apunta al último commit de esa rama. Si un usuario cambia a otra rama con git checkout, ¿qué ocurre con HEAD?

1. HEAD se actualiza para apuntar a la referencia de la nueva rama activa.
2. HEAD permanece apuntando a la rama anterior hasta que se ejecute git commit.
3. HEAD se elimina y se genera un nuevo apuntador llamado ORIG_HEAD en su lugar.
4. HEAD se transforma en una copia estática del último commit confirmado, independiente de la rama activa.

HEAD es un apuntador simbólico a la rama en la que se está trabajando; al cambiar de rama con git checkout, HEAD se actualiza para señalar la nueva rama activa. ("Pro Git" (2ª ed.), cap. 3 "Branches in a Nutshell", git-scm.com/book)

32. El estándar de Versionado Semántico (SemVer 2.0.0) define un número de versión compuesto por tres componentes numéricos separados por puntos. ¿Cuál es el orden correcto de esos componentes?

1. PATCH.MINOR.MAJOR
2. MAJOR.MINOR.PATCH
3. MINOR.MAJOR.PATCH
4. MAJOR.PATCH.MINOR

SemVer 2.0.0 especifica el formato MAJOR.MINOR.PATCH, donde cada componente se incrementa según reglas específicas de compatibilidad. (Semantic Versioning 2.0.0, punto 2, semver.org)

33. Una biblioteca se encuentra en la versión 2.4.7. El equipo agrega una función nueva que no rompe la compatibilidad con el código existente que ya usa la biblioteca. Según las reglas de SemVer 2.0.0, ¿cuál debe ser el número de la siguiente versión publicada?

1. 3.0.0
2. 2.4.8
3. 2.5.0
4. 2.5.7

Agregar funcionalidad compatible hacia atrás incrementa MINOR (2.4 a 2.5) y reinicia PATCH a 0, resultando en 2.5.0; subir a MAJOR (3.0.0) sería incorrecto porque el cambio no rompe compatibilidad, y avanzar solo PATCH (2.4.8) o no reiniciar PATCH (2.5.7) son errores típicos de aplicar mal la regla de incremento. (Semantic Versioning 2.0.0, puntos 6, 7 y 8, semver.org)

34. Un equipo ya publicó (hizo push) una rama de característica a un repositorio remoto compartido, y otros dos integrantes ya bajaron esos commits para seguir trabajando sobre ellos. Un desarrollador propone usar git rebase sobre esa rama compartida para "limpiar" el historial antes de continuar. ¿Qué recomienda la buena práctica de Git en este caso?

1. Rebasar de inmediato toda la rama compartida, dado que git rebase conserva los mismos identificadores en los commits reaplicados.
2. Rebasar la rama después de eliminar la referencia remota con git branch -D, para luego reescribir la historia sin conflicto.
3. Rebasar primero los commits más recientes de la rama principal (main) y dejar para después los de la rama de característica.
4. No rebasar los commits que ya se publicaron en el repositorio compartido, porque reescribe la historia y genera conflictos para quienes ya la descargaron.

La regla de oro de git rebase es no reescribir commits que ya se publicaron en un repositorio compartido, porque el rebase genera nuevos identificadores para los commits reaplicados y complica el trabajo de quienes ya los tienen. ("Pro Git" (2ª ed.), cap. 3 "The Perils of Rebasing", git-scm.com/book)

35. Un equipo adopta Integración Continua siguiendo la práctica descrita por Martin Fowler. Además de contar con una compilación automática que verifique cada cambio, ¿con qué frecuencia mínima debería cada integrante fusionar su trabajo con la rama compartida?

1. Al menos una vez al día.
2. Al menos una vez por semana.
3. Solamente al finalizar cada sprint.
4. Únicamente antes de cada despliegue a producción.

Fowler describe que en CI cada persona típicamente integra su trabajo al menos una vez al día, generando múltiples integraciones diarias verificadas por una compilación automática; integrar por sprint o solo antes de desplegar no cumple con la práctica de CI. (Martin Fowler, "Continuous Integration" (rev. 2006), martinfowler.com)