Introducción
La guía de Harbour Loop que sigue recibiendo soporte necesita una corrección en el enlace de descarga. Desarrollo ya contiene esa corrección, junto con un rediseño Explorer no aprobado. El árbol de trabajo original de main todavía tiene trabajo preparado del plan fotográfico, un borrador adicional de cubierta sin preparar y una nota privada sin seguimiento.
Usa la técnica de árboles de trabajo del primer laboratorio guiado para dar a la rama de mantenimiento existente un directorio de trabajo limpio. Lee los parches reales, selecciona la única corrección que es autosuficiente y aplica solo ese cambio con cherry-pick. Después prueba la descarga útil de la edición antigua y verifica que ni el rediseño ni tu trabajo sin terminar hayan entrado en la versión.
Este módulo inicializa sus propios repositorios y archivos; no reutiliza la VM anterior. Los requisitos previos son conocimientos básicos de terminal/commit/branch/log/diff y los conceptos de árbol de trabajo vinculado y archivos pequeños enseñados en el primer laboratorio guiado. No se necesita código de sitio web ni una cuenta de un servicio alojado. Usa Workspace y Release Desk. La vista previa real de Git/HTTP es local a una única máquina de formación y lee commits de ramas, no ediciones de archivos de trabajo. Todas las rutas de los paseos y las identidades son sintéticas. La duración de 40 minutos es una estimación del autor.
Identifica la corrección y abre el árbol de trabajo de mantenimiento
En este paso, verás la descarga esperada, distinguirás la corrección aislada del rediseño y abrirás la rama antigua existente sin alterar main.
Abre Release Desk y después Open supported release. Verifica Harbour Loop, Pocket Edition 1.0, 3.2 km y North Pier. Usa Download quick start, abre quick-start.txt desde la lista de descargas del navegador y comprueba el punto de encuentro original y la lista breve de preparación.
Usa Download full guide. Se espera la página 404 real Guide not found; después haz clic en Back to release. El servicio es accesible, pero el enlace de esta versión apunta a un archivo que no contiene.
Usa All releases y después Open development preview. Explorer Edition 2.0 no está aprobada. Su Download full guide ya funciona: abre harbour-guide-v1.txt desde tu lista de descargas y lee las tres indicaciones originales, el inicio en North Pier, la distancia de 3.2 km y el recordatorio sobre caminos y basura. Conserva esa corrección útil y deja fuera el rediseño. Usa All releases para volver.
Cambia a Workspace y entra explícitamente en el directorio de trabajo original:
cd /home/labex/project/release-desk/editor
Para errores habituales de ruta, usa pwd y ls y después repite este comando cd completo; no reinicies la VM. Configura una identidad de autor local para el repositorio. --local afecta a este repositorio y a sus árboles de trabajo vinculados, no a la configuración global. Puedes reemplazar los ejemplos sintéticos entre comillas:
git config --local user.name "Guide Editor"
git config --local user.email "guides@example.com"
Lee el estado sin terminar antes de hacer mantenimiento:
git branch --show-current
git status --short
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
cat private-note.txt
Como en el primer laboratorio, se esperan main, MM preview.txt y ?? private-note.txt. La primera diferencia muestra la incorporación preparada Plan: add dusk photographs.. La segunda muestra la incorporación adicional sin preparar Draft: try the violet cover.. Conserva sus contenidos distintos y la nota privada. --cached selecciona la comparación entre el índice y el commit; la comparación simple compara los archivos de trabajo con el índice. --no-pager muestra la salida directamente y -- separa la ruta que sigue.
Lee el historial de desarrollo guardado en commits. --oneline abrevia cada entrada y --decorate etiqueta los punteros y tags:
git --no-pager log --oneline --decorate dev-start
La etiqueta fija dev-start marca la punta recibida de main. De más reciente a más antiguo, el historial preparado contiene Plan the Explorer photo collection, Correct the Harbour Loop download link, Introduce the Explorer redesign y Prepare the supported Harbour Loop guide. Conserva la etiqueta y la punta de main sin cambios.
Inspecciona el cambio más reciente antes de elegirlo. show muestra un commit seleccionado y su parche:
git --no-pager show dev-start
Modifica explorer-plan.txt. Es trabajo futuro no relacionado. La corrección está un padre antes de este marcador fijo. ~1 selecciona ese padre sin cambiar tu checkout:
git --no-pager show dev-start~1
Su parche completo modifica solo la línea de full-guide.path: /downloads/harbour-guid-v1.txt pasa a ser /downloads/harbour-guide-v1.txt. Esta corrección es autosuficiente; no requiere el rediseño. Inspecciona también ese rediseño anterior. ~2 sigue la relación de padre dos pasos hacia atrás desde el marcador fijo y selecciona un único commit antecesor:
git --no-pager show dev-start~2
Cambia la identidad de la versión y añade planes Explorer. Fusionar toda la rama de desarrollo importaría esos cambios no aprobados además de la corrección útil.
Abre la rama con soporte existente junto a main. .. identifica el directorio padre y el segundo argumento elige explícitamente la rama existente en lugar de crear una nueva a partir de main:
git worktree add ../supported-v1 release/1.0
git worktree list
cd ../supported-v1
git branch --show-current
git status --short
cat release.txt
Se espera que la lista nativa de árboles de trabajo incluya ambos directorios, la rama release/1.0, un estado de mantenimiento limpio y la identidad Pocket Edition 1.0. Su índice separado da a cherry-pick el destino limpio que necesita mientras el borrador de main permanece en su lugar. Si por error solicitas añadir main otra vez, el rechazo por rama ya extraída enseñado en el primer laboratorio no requiere forzar ni hacer reset: inspecciona git worktree list y usa la rama con soporte existente.
Aplica la corrección y verifica la versión conservada
En este paso, aplicarás solo el parche seleccionado a la versión antigua, probarás la guía real y confirmarás que el trabajo original de desarrollo está intacto.
Permanece en Workspace, en /home/labex/project/release-desk/supported-v1. Un cherry-pick toma el cambio introducido por un commit seleccionado y lo aplica en tu rama actual, normalmente registrando un nuevo commit. No fusiona todos los antecesores del commit seleccionado. En este escenario, la rama antigua tiene un padre distinto del de la corrección de origen, por lo que la nueva corrección tiene su propio identificador de commit.
Lee una vez el enlace antiguo y después aplica la corrección aislada inspeccionada. La etiqueta sigue siendo visible desde cualquiera de los árboles de trabajo vinculados porque los objetos y las referencias del repositorio son compartidos:
cat full-guide.path
git cherry-pick dev-start~1
Se espera un nuevo commit con el asunto del enlace de descarga y un cambio en un archivo, sin conflicto. Este parche preparado cambia la misma configuración pequeña en la base con soporte; no tiene una cadena de dependencias. Tu identificador de commit puede ser distinto.
Revisa exactamente qué ha ganado la rama de mantenimiento. La etiqueta fija supported-start marca la punta antigua recibida, HEAD es el commit actual de este árbol de trabajo y diff compara esas instantáneas:
git --no-pager diff supported-start HEAD
Se espera solo la corrección de la ruta de la guía completa. No debería haber cambios en release.txt, el contenido de la guía ni el texto original de la vista previa, ni ningún archivo exclusivo de Explorer. Inspecciona el historial real y el estado limpio del destino:
git --no-pager log --oneline --decorate
git status --short
cat release.txt
Debería haber una corrección directamente después del commit original con soporte. Los commits de desarrollo del rediseño y el plan fotográfico no están en la ascendencia de esta rama. La redacción exacta del mensaje no es el criterio de éxito; lo son el parche aislado, la base correcta y los archivos conservados.
Cambia a Release Desk, haz clic en Release Desk en la cabecera para volver a la vista general y después en Open supported release. Debe conservar Pocket Edition 1.0, Harbour Loop, 3.2 km y North Pier. La vista previa local lee el commit de la rama que acabas de hacer avanzar; no se simula ningún despliegue remoto ni en producción.
Haz clic en Download full guide. Abre el archivo real harbour-guide-v1.txt desde la lista de descargas de tu navegador. Compara el contenido completo con la descarga de desarrollo que leíste antes: inicio en North Pier; las tres indicaciones que pasan por Clock Steps, el antiguo cobertizo de barcos y Anchor Square; 3.2 km; y el recordatorio final sobre caminos y basura. La corrección entrega la guía original con soporte, no una ruta Explorer nueva. El enlace de descarga por sí solo o un código de estado correcto no demostrarían que el contenido está completo.
Usa Download quick start y conserva su lista original. Desde All releases, abre la vista previa de desarrollo y confirma que Explorer Edition 2.0 no haya cambiado. Vuelve con All releases.
Cambia a Workspace y vuelve a entrar en el directorio original de main. Estar en otro directorio cambia el índice de qué árbol de trabajo inspeccionan tus comandos. La opción -1 de log limita la salida al commit más reciente:
cd /home/labex/project/release-desk/editor
git branch --show-current
git --no-pager log -1 --oneline --decorate
git status --short
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
cat private-note.txt
El commit más reciente debe seguir siendo el commit original del plan fotográfico marcado por dev-start. Se esperan los estados originales de main MM preview.txt y ?? private-note.txt, la misma frase preparada del plan fotográfico, la frase separada sin preparar de la cubierta violeta y la nota privada sin cambios. No los guardes en un commit ni los descartes solo para limpiar el estado. Deja disponible el árbol de trabajo con soporte. El punto de comprobación verifica la relación vinculada, el historial con soporte y todos los archivos requeridos, junto con las descargas reales y la conservación de main.
Resumen
Inspeccionaste los parches reales de desarrollo, seleccionaste la corrección aislada del enlace y la aplicaste mediante cherry-pick en el árbol de trabajo de mantenimiento limpio. La versión antigua recibió una corrección útil sin heredar el rediseño.
Las descargas de la guía completa y del inicio rápido siguieron completas, mientras que la punta de la rama de desarrollo, las versiones preparada y sin preparar del borrador y la nota privada permanecieron intactas. El desafío independiente cambia la rama con soporte, la guía y la posición de la corrección, así que selecciona a partir de las pruebas en lugar de copiar un desplazamiento.
