Importante:

IBM Cloud Pak® for Data La versión 4.7 alcanzará el fin de soporte (EOS) el 31 de julio de 2025. Para más información, consulte el anuncio de interrupción del servicio para la versión IBM Cloud Pak for Data 4.X.

Actualice a IBM Software Hub Versión 5.1 antes de que IBM Cloud Pak for Data Versión 4.7 alcance el fin de soporte. Para más información, consulte Actualización de IBM Software Hub en la documentación de la versión IBM Software Hub 5.1.

Operaciones Git

En un proyecto con integración de Git predeterminada, no es necesario que el repositorio Git asociado con el proyecto esté vacío cuando se crea el proyecto. Por ejemplo, si ha desarrollado código en un IDE en la estación de trabajo y desea pasar a un proyecto en Cloud Pak for Data, puede clonar el repositorio que ya contiene el código y continuar trabajando en JupyterLab en el proyecto basándose en el contenido del archivo extraído del repositorio.

Puede realizar operaciones Git desde:

  • Dentro de los IDEs JupyterLab o RStudio en un proyecto

  • La barra de acciones de un proyecto seleccionando el icono Git (Muestra el icono Git .). Puede seleccionar las siguientes operaciones de Git :

    • Pull: extrae los cambios más recientes de la rama remota del repositorio al proyecto

      Si es nuevo en el proyecto y no ha creado una señal de acceso al repositorio, se le solicitará que cree una.

    • Confirmar: confirma los cambios locales sin seguimiento en la rama clonada

    • Push: envía los cambios locales a la rama remota para habilitar el seguimiento por parte de otros

    • Extraer rama: habilita la selección o conmutación de la rama Git para el proyecto

    • Conflicto de fusión: permite seleccionar la versión de archivo (local o remota) que se debe utilizar para fusionar

      Si Git no puede fusionarse automáticamente, puede optar por abandonar sus propios cambios utilizando la copia remota del archivo o abandonar los cambios entrantes utilizando su propia copia del archivo.

      Para cualquier archivo en el que desee conservar los cambios local y remoto, no seleccione ni local ni remoto y, en su lugar, resuelva el conflicto manualmente. Puede utilizar el terminal de proyecto para resolver conflictos complejos manualmente. Consulte Terminal de proyecto. Para los archivos .ipynb de cuaderno, debe ir a Jupyterlab donde puede ver los cambios de archivo y resolver los conflictos de fusión visualmente. Consulte Fusión de conflictos.

    • Historial de confirmaciones: registra el historial de confirmaciones

Fusionar escenarios de conflicto

Los siguientes escenarios muestran cómo pueden surgir conflictos de fusión al realizar operaciones Git y cómo resolverlos mejor:

  • Utilización de credenciales privadas para una conexión:

    • User1 crea una nueva conexión y un activo de datos conectado asociado en la interfaz de proyecto. User1 proporciona credenciales privadas para la conexión.
    • User1 confirma y envía este cambio a la rama remota.
    • User2 extrae este cambio de la rama remota y ve la nueva conexión y el activo de datos conectado en la página Activos del proyecto.
    • Cuando user2 utiliza la conexión o el activo de datos conectado por primera vez, se solicita a user2 que proporcione las credenciales privadas. User1 debe proporcionar user2 con las credenciales.

  • Cómo trabajar en el mismo archivo de cuaderno en una rama de característica:

    • User1 y user2 realizan cambios conflictivos en un archivo de cuaderno, pero user2 confirma y envía por push primero.
    • Cuando user1 extrae estos cambios antes de la confirmación, user1 ve un conflicto a nivel de archivo en el archivo ipynb .
    • User1 determina qué cambio se debe mantener directamente en la interfaz de usuario Git del proyecto. De forma alternativa, user1 puede ir a Jupyterlab para examinar y fusionar los cambios.

  • Cómo trabajar en el mismo flujo de Data Refinery en una rama de característica:

    • User1 y user2 realizan cambios conflictivos en un flujo de Data Refinery existente, pero user2 se confirma y se envía primero. Los cambios en un flujo de Data Refinery afectan a los archivos de los directorios assets/.METADATA y assets/data_flow .
    • Cuando user1 extrae estos cambios antes de confirmar, user1 ve que hay un conflicto.
    • Desde el nombre de archivo, user1 puede determinar en qué flujo de Data Refinery se está produciendo este conflicto. User1 determina qué cambio se debe conservar y realiza los cambios en el archivo en los directorios assets/.METADATA y assets/data_flow .

  • Los cambios en un archivo Python de programa de utilidad en una rama de característica interrumpe un script de llamada:

    • User1 confirma y envía los cambios a un archivo Python de programa de utilidad en la rama de característica.
    • User2 extrae los cambios de user1del repositorio remoto.
    • No se producen conflictos, sin embargo, user2 descubre el cambio de interrupción durante la prueba.
    • User2 arregla el script de llamada antes de confirmar y enviar por push los cambios.

  • Resolución de cambios conflictivos en la descripción de un activo de datos en una rama de característica en la interfaz de usuario Git del proyecto:

    • User1 y user2 realizan cambios conflictivos en la descripción de un activo de datos, pero user2 se compromete y envía por push en primer lugar.
    • Cuando user1 extrae los cambios de user2antes de confirmar, user1 ve que se produce un conflicto en el archivo .json correspondiente en el directorio assets/.metadata .
    • A partir del nombre de archivo, user1 puede determinar en qué activo se está produciendo este conflicto. User1 determina qué cambio se debe mantener.

  • Resolución de cambios conflictivos en la descripción de un activo de datos en una rama de características en JupyterLab:

    • User1 y user2 realizan cambios conflictivos en la descripción de un activo de datos, pero user2 se compromete y envía por push en primer lugar.
    • Cuando user1 extrae los cambios de user2antes de confirmar, user1 ve que se produce un conflicto en el archivo .json correspondiente en el directorio assets/.metadata .
    • A partir del nombre de archivo, user1 puede determinar en qué activo se está produciendo este conflicto. User1 cancela la fusión.
    • Cuando user1 busca ese activo en la página Activos del proyecto para ver los detalles, se muestra un mensaje de error que indica que el activo no existe.
    • User1 abre Jupyterlab e inicia una ventana de terminal. User1 navega al directorio .metadata y edita el archivo para resolver el conflicto combinando la información de las dos descripciones.
    • User1 ejecuta el mandato de adición Git para marcar que el conflicto se ha resuelto para ese archivo, confirma en la interfaz de usuario del proyecto que el conflicto ya no existe y confirma y envía los cambios.

Tema padre: Integración de Git predeterminada