Creación y administración de carpetas de Git

En esta página se describe cómo crear carpetas de Git de Azure Databricks y realizar operaciones comunes de Git, incluida la clonación, la bifurcación, la confirmación y la inserción.

En esta guía se describen las siguientes operaciones de Git:

Clonación de un repositorio

Al clonar un repositorio remoto, Databricks crea una carpeta git en el área de trabajo que contiene el contenido del repositorio y realiza un seguimiento de los cambios. Puede crear carpetas de Git mediante la interfaz de usuario de Azure Databricks o el terminal web.

Clonar desde la interfaz de usuario

1. En la barra lateral, seleccione Área de trabajo y vaya a la carpeta donde desea crear el clon del repositorio de Git.

2. Haga clic en Crear>carpeta git.

3. En el cuadro de diálogo Crear carpeta Git, proporcione la siguiente información:

   Campo	Description
   URL del repositorio de Git	Dirección URL del repositorio de Git que desea clonar, con el formato https://example.com/organization/project.git.
   Proveedor de GIT	Proveedor de Git para el repositorio que desea clonar.
   Nombre de carpeta de Git	Nombre de la carpeta del área de trabajo que contiene el contenido del repositorio clonado.
   Modo de checkout disperso	Si se desea utilizar el checkout disperso, que clona solo un subconjunto de los directorios de tu repositorio utilizando un patrón de cono. Esto resulta útil si el repositorio supera los límites de tamaño.

4. Haga clic en Crear carpeta Git. El contenido del repositorio remoto se clona en el área de trabajo y puede empezar a trabajar con operaciones de Git compatibles. Cuando tu espacio de trabajo cumple los requisitos, la carpeta Git se crea automáticamente con acceso a Git CLI. Consulte ¿Cuándo obtiene una carpeta de Git acceso a la CLI de Git?.

Clonar desde el terminal web

También puede crear carpetas de Git con acceso de la CLI directamente desde el terminal web:

1. Acceda al terminal web. Consulte Ejecución de comandos de shell en el terminal web de Azure Databricks.

2. Vaya al directorio primario en /Workspace:

   cd /Workspace/Users/<your-email>/<project>
   

3. Clona tu repositorio:

   git clone <remote-url>
   

   El git clone comando usa las credenciales de Git configuradas en el área de trabajo. Consulte Conexión del proveedor de Git a Databricks.

4. Actualice el explorador para ver la nueva carpeta en el explorador de archivos del área de trabajo.

Uso de comandos de la CLI de Git

Las carpetas de Git con acceso a la CLI de Git permiten ejecutar comandos de Git estándar en proceso sin servidor, desde un cuaderno, el terminal web o Genie Code. Ustedes pueden:

• Ejecute cualquier comando de Git, incluidos git stash, git push --forcey git rebase -i.
• Integra la validación de código y el análisis de código con hooks de pre-commit.
• Trabaje con repositorios que superen los límites de 2 GB de memoria y 4 GB de disco de las carpetas de Git estándar.
• Usar submódulos de Git y Almacenamiento de Archivos Grandes (LFS).
• Realiza varias confirmaciones localmente antes de enviarlas al repositorio remoto.

Requisitos de proceso de la CLI de Git

El proceso necesario depende de cómo use una carpeta git habilitada para la CLI:

Para habilitar el proceso sin servidor, consulte Conexión al proceso sin servidor.

Si el proveedor de Git requiere conectividad de red privada, consulte Configuración de la conectividad de red.

¿Cuándo obtiene una carpeta de Git acceso a la CLI de Git?

Al crear una carpeta de Git desde la interfaz de usuario, Azure Databricks habilita automáticamente el acceso a la CLI de Git si el área de trabajo es apta. Si el área de trabajo no es apta, Azure Databricks crea una carpeta de Git estándar en su lugar y todavía puede realizar operaciones de Git desde la interfaz de usuario de carpetas de Git.

Una carpeta de Git que cree a partir de la interfaz de usuario obtiene acceso a la CLI de Git cuando se cumplen todas las siguientes condiciones:

• La versión preliminar de la CLI de Git está habilitada para el área de trabajo. Los administradores del área de trabajo controlan esto desde la página Vistas previas . Consulte Administración de versiones preliminares de Azure Databricks.
• La computación sin servidor está disponible en su espacio de trabajo. Véase Conexión a la computación sin servidor.
• Azure Databricks puede acceder a su proveedor de Git desde la computación sin servidor. Azure Databricks comprueba la conectividad antes de clonar el repositorio. Si el proveedor de Git requiere conectividad de red privada, consulte Configuración de la conectividad de red.
• Durante la versión preliminar pública, los repositorios están limitados a 10 000 archivos. En su lugar, los repositorios que superan este límite se clonan como carpetas de Git estándar.

Las carpetas de Git que clone desde el terminal web siempre tienen acceso a la CLI de Git.

Creación de una carpeta de Git con acceso a la CLI de Git

Para crear una carpeta de Git con acceso a la CLI:

• Si usa la interfaz de usuario, Azure Databricks crea la carpeta Git con acceso de la CLI de Git automáticamente cuando el área de trabajo es apta. Consulte ¿Cuándo obtiene una carpeta de Git acceso a la CLI de Git?. Si el área de trabajo no es apta, Azure Databricks crea en su lugar una carpeta git estándar.
• Si usa el terminal web, cualquier repositorio que clone tenga acceso a la CLI de Git automáticamente.

Después de crear una carpeta de Git con acceso a la CLI, ejecute cualquier comando de Git estándar desde el terminal web. Para abrir un terminal web, consulte Iniciar el terminal web.

cd /Workspace/Users/<your-email>/<project>/my-repo

# Interactive rebase
git rebase -i main

# Stash uncommitted changes
git stash

# Work with submodules
git submodule update --init --recursive

Limitaciones de la CLI de Git

Las carpetas de Git con acceso a la CLI tienen las siguientes limitaciones:

• Las listas de direcciones URL permitidas de Git se aplican a las operaciones de Git que ejecutas desde la interfaz de usuario de Azure Databricks, pero no se aplican a los comandos de Git que ejecutas directamente mediante la CLI de Git.
• Las carpetas Git con acceso mediante la CLI de Git no se devuelven mediante la API List Repos.

Solución de problemas de operaciones de la CLI de Git

• Las operaciones de Git están deshabilitadas en la interfaz de usuario del área de trabajo: el proceso sin servidor no está habilitado en el área de trabajo. Todavía puede ejecutar comandos de Git desde el terminal web. Para habilitar el proceso sin servidor, consulte Conexión al proceso sin servidor.
• El terminal le pide que seleccione una credencial: las operaciones de la CLI de Git usan automáticamente las credenciales de Git del área de trabajo almacenadas. Azure Databricks deduce el proveedor de Git desde la dirección URL remota y usa la credencial predeterminada para ese proveedor. Si Azure Databricks no puede identificar una sola credencial que se va a usar, se le pedirá que seleccione una. Para evitar el mensaje, establezca la DB_GIT_CREDENTIAL_NAME variable de entorno en el nombre de la credencial que desea usar. Azure Databricks recuerda la credencial que usa para un repositorio y la reutiliza.
• Las operaciones de Git producen errores de permiso: compruebe que tiene CAN MANAGE permiso en la carpeta primaria y que las credenciales de Git del área de trabajo son válidas. Consulte Conexión del proveedor de Git a Databricks.

Acceso al cuadro de diálogo de Git

Acceda al cuadro de diálogo de Git desde un cuaderno o desde el explorador de carpetas de Git de Azure Databricks.

• En un cuaderno, haga clic en el botón situado junto al nombre del cuaderno que identifica la rama de Git actual.

  

• En el explorador de carpetas git de Azure Databricks, haga clic en Git junto al nombre del repositorio.

Aparece un cuadro de diálogo de pantalla completa donde puede realizar operaciones de Git.

1. La rama de trabajo actual. Puede seleccionar otras ramas aquí. Si otros usuarios tienen acceso a esta carpeta de Git, al cambiar la rama también se cambia la rama para ellos si comparten la misma área de trabajo. Consulte una práctica recomendada para evitar este problema.
2. Crear una nueva rama.
3. Los archivos y subcarpetas se incorporan a tu rama actual.
4. Muestra el historial de la rama actual.
5. Extraiga contenido del repositorio de Git remoto.
6. Agregue un mensaje de confirmación y una descripción expandida opcional para los cambios.
7. Confirma tu trabajo en la rama de trabajo y envía la rama actualizada al repositorio remoto de Git.

Haz clic en el menú de tres puntos para elegir entre operaciones adicionales de ramas de Git, como un restablecimiento completo, una fusión o un rebase.

Creación de una rama

Para crear una nueva rama:

1. Abra el cuadro de diálogo git.
2. Haga clic en Crear rama.
3. Escriba un nombre para la nueva rama y seleccione la rama base.
4. Haga clic en Crear.

Cambiar a otra rama

Para cambiar a otra rama, use la lista desplegable de ramas en el cuadro de diálogo de Git.

Los cambios no confirmados en la rama actual se transfieren y se muestran como cambios no confirmados en la nueva rama, si los cambios no confirmados no entran en conflicto con el código de la nueva rama. Descarta los cambios realizados antes o después de cambiar de rama si no deseas conservar los cambios no confirmados.

La versión local de una rama puede permanecer presente en la carpeta git asociada durante hasta 30 días después de eliminar la rama remota. Para quitar completamente una rama local en una carpeta de Git, elimine el repositorio.

Confirma y envía los cambios

Al agregar nuevos blocs de notas o archivos, o realizar cambios en los archivos o cuadernos existentes, la interfaz de usuario de la carpeta Git resalta los cambios.

Agregue un mensaje de confirmación necesario para los cambios y haga clic en Confirmar e insertar para insertar los cambios en el repositorio de Git remoto.

Si no tiene permiso para realizar commits en la rama predeterminada, cree una nueva rama y use la interfaz de usuario de su proveedor de Git para crear un pull request y fusionarla en la rama predeterminada.

Realizar confirmaciones en una carpeta de Git mientras se actúa como un rol

Con RBAC, adoptas un rol para acceder a los datos restringidos a ese rol. Para crear código que lea esos datos, asuma el rol para que su acceso a datos esté en vigor y, a continuación, confirme los cambios. Puedes realizar confirmaciones tanto con tu propia identidad de usuario como con la del rol. Esta elección determina cómo tu proveedor de Git atribuye las confirmaciones, lo cual se contrapone a la cantidad de configuración que requiere el flujo de trabajo. Ambos dependen de las credenciales de Git asociadas al rol.

Confirmar con su identidad de usuario

En este enfoque, haces confirmaciones con tu credencial personal de Git, por lo que tu proveedor de Git te atribuye esas confirmaciones. Usted asume el rol únicamente para crear contenido sobre los datos a los que el rol tiene acceso y, a continuación, vuelve a su identidad de usuario para realizar la confirmación. Dado que creas el contenido mientras actúas en el rol, pero realizas el commit con tu identidad de usuario, la carpeta de Git debe ser accesible desde ambas identidades. Puedes configurarlo de dos maneras, que difieren en quién es el propietario de la carpeta y en qué sentido la compartes.

Opción 1: Clonar en la carpeta principal y compartirla con el rol

1. Con tu identidad de usuario (sin asumir el rol), clona el repositorio en una carpeta Git de tu carpeta de inicio (/Workspace/Users/<your-username>/...). Consulte Clonación de un repositorio. El clon usa su credencial de Git personal y posee la carpeta . El rol no necesita su propia credencial de Git para esta opción.
2. Conceda al rol acceso a la carpeta (Puede ejecutar o Puede editar si el rol necesita modificar archivos) para que pueda trabajar en ella mientras actúa como rol.
3. Asuma el rol y, a continuación, realice los cambios en la carpeta . El acceso a los datos del rol está activo.
4. Vuelva a la identidad del usuario y, a continuación, confirme e inserte. La confirmación utiliza tu git_username y git_email personales.

Dado que comparte la carpeta de la identidad de usuario con el rol, los controles de uso compartido de recursos del área de trabajo no afectan a esta opción. Esos controles solo impiden que un rol comparta activos externamente.

Opción 2: Clonar en la carpeta de inicio del rol y compartirla con su identidad de usuario

1. Asuma el rol y clone el repositorio en una carpeta Git dentro del directorio personal del rol. El clon usa la credencial de Git del rol, que debe tener al menos acceso de lectura.
2. Mientras actúas como el rol, concede a tu identidad de usuario acceso a la carpeta (Puede editar).
3. Haga los cambios mientras desempeña ese rol. El acceso a los datos del rol está activo.
4. Vuelve a tu identidad de usuario. Como has concedido acceso a tu usuario, puedes acceder a la carpeta, así que confirma los cambios y haz push con tus credenciales personales. La confirmación utiliza tu git_username y git_email personales.

Dado que el rol comparte la carpeta externamente con tu identidad de usuario, esta opción no funciona si el rol está en la lista de bloqueo de controles de uso compartido de recursos del espacio de trabajo. Use la opción 1 para esos roles.

Realizar el commit como el rol

En este método, clonas, creas y realizas el commit mientras actúas como el rol. Este es el flujo de trabajo más sencillo: no comparte una carpeta ni cambia las identidades para confirmar. Requiere que la credencial Git del rol tenga acceso de escritura, ya que la interfaz de usuario del espacio de trabajo realiza el commit y el push en una sola acción.

1. Asuma el rol.
2. Clone el repositorio en una carpeta de Git. Como estás actuando como el rol, la clonación utiliza la credencial Git del rol.
3. Realice los cambios y, a continuación, confirme y envíe. La confirmación utiliza git_username y git_email del rol.

Pesa estas implicaciones antes de elegir este enfoque:

• La atribución es a nivel de rol. Los commits en tu proveedor de Git muestran la identidad de Git asociada al rol, no la del autor individual. Los registros de auditoría de Azure Databricks registran tanto identity_metadata.run_as (el rol) como identity_metadata.run_by (usted) para las confirmaciones realizadas a través de la interfaz de usuario del área de trabajo. Esto no se aplica a los commits de Git sin procesar realizados desde la línea de comandos de Git en un terminal web, que Azure Databricks no atribuye a ningún usuario concreto.
• La credencial de Git asociada al rol se comparte y tiene permisos de escritura. Cualquier persona que asuma el rol utiliza las mismas credenciales para enviar, por lo que un token filtrado o utilizado indebidamente puede enviar, eliminar ramas o crear confirmaciones con la identidad del rol. Por este motivo, Azure Databricks recomienda utilizar una credencial de Git de grupo de solo lectura y el enfoque de confirmar con tu identidad de usuario. Utilice credenciales con permisos de escritura solo cuando acepte estas contrapartidas. Consulte Permisos de token. Limite el alcance de la credencial solo a los repositorios que necesita el rol.

Incorporación de cambios

Para extraer los cambios del repositorio de Git remoto, haga clic en Pull en el cuadro de diálogo operaciones de Git. Los cuadernos y otros archivos se actualizan automáticamente a la versión más reciente del repositorio de Git remoto. Si los cambios extraídos del repositorio remoto entran en conflicto con los cambios locales en Azure Databricks, resuelva los conflictos de combinación.

Colaboración en carpetas de Git

Las carpetas de Git de Azure Databricks se comportan como clientes de Git insertados en el área de trabajo, lo que le permite colaborar a través del control de código fuente basado en Git y el control de versiones. Para una colaboración en equipo eficaz:

• Cada miembro del equipo tiene su propia carpeta de Git asignada al repositorio de Git remoto, donde trabajan en su propia rama de desarrollo.
• Solo un usuario realiza operaciones de Git en cada carpeta de Git. Varios usuarios que realizan operaciones de Git en la misma carpeta pueden provocar problemas de administración de ramas, como un usuario que cambia accidentalmente las ramas para todos.

Para compartir la configuración de la carpeta git con un colaborador:

1. Haga clic en Compartir.
2. Haga clic en el vínculo Copiar para crear una carpeta de Git.
3. Envíe la dirección URL al colaborador.
4. Cuando el colaborador abra la dirección URL, verá un cuadro de diálogo rellenado previamente con la configuración de la carpeta Git.
5. Hacen clic en Crear carpeta git para clonar el repositorio en su propia área de trabajo en su carpeta de trabajo actual.

Fusionar ramas

La función merge de las carpetas de Git de Azure Databricks usa git merge para combinar el historial de confirmaciones de una rama en otra. Para los principiantes de Git, Databricks recomienda usar merge en lugar de rebase porque no requiere un empuje forzado y no reescribe el historial de confirmaciones.

Para combinar una rama en otra, haga clic en el Menú kebab y seleccione Combinar.

• Si hay un conflicto de combinación, resuélvalo en la interfaz de usuario de carpetas de Git.
• Si no hay ningún conflicto, la fusión se envía al repositorio de Git remoto mediante git push.

Resolución de conflictos de combinación

Los conflictos de combinación se producen cuando Git no puede conciliar automáticamente los cambios en las mismas líneas de un archivo de orígenes diferentes, como durante una operación de extracción, rebase o combinación.

Para resolver un conflicto de combinación, use la interfaz de usuario de carpetas de Git que muestra los archivos en conflicto y las opciones de resolución.

• Edite manualmente el archivo para elegir qué cambios se van a conservar.
• Seleccione Mantener todos los cambios actuales o Tomar todos los cambios entrantes para aceptar una versión por completo.
• Anule la operación y descarte los cambios en conflicto para intentarlo de nuevo.

Resolución manual de conflictos

La resolución manual de conflictos permite determinar qué líneas conflictivas se van a aceptar. Edite el contenido del archivo directamente para resolver los conflictos.

Para resolver el conflicto, seleccione las líneas de código que desea conservar y eliminar todo lo demás, incluidos los marcadores de conflicto de combinación de Git. Cuando haya terminado, seleccione Marcar como resuelto.

Si ha realizado las opciones incorrectas al resolver conflictos de combinación, haga clic en Anular para anular el proceso y deshacer todo. Una vez resueltos todos los conflictos, haz clic en Continuar con la fusión o en Continuar con el rebase para resolver el conflicto y completar la operación.

Rebase una rama

La función rebase en las carpetas de Git de Azure Databricks usa git rebase para integrar los cambios de una rama en otra mediante la nueva aplicación de las confirmaciones en la parte superior de la rama de destino, creando un historial lineal.

Para volver a basar una rama en otra rama, haga clic en el Menú kebab y seleccione Rebase y, a continuación, seleccione la rama de destino.

• Tras el rebase, Git ejecuta los pasos git commit y git push --force para actualizar el repositorio remoto.
• Rebase vuelve a escribir el historial de confirmaciones, lo que puede provocar problemas de control de versiones para los colaboradores que trabajan en el mismo repositorio.

Resetear una rama

Realice un restablecimiento de Git desde la interfaz de usuario de carpetas de Git. Esta operación es equivalente a git reset --hard combinada con git push --force.

Git reset reemplaza el historial y el contenido de la rama con el estado más reciente de otra rama. Puede usar esto cuando las ediciones entren en conflicto con la rama ascendente y no le importe perder esas modificaciones al restablecer a la rama ascendente. Obtenga más información sobre git reset --hard.

Restablecer a una rama remota

Con git reset en este escenario:

• Debes restablecer la rama seleccionada (por ejemplo, feature_a) a otra rama diferente (por ejemplo, main).
• También restablezca la rama feature_a ascendente (remota) a main.

Para restablecer una rama a una rama remota:

1. En la interfaz de usuario de carpetas de Git del menú Rama, elija la rama que desea restablecer.

2. Seleccione Restablecer en el Menú kebab.

   

3. Seleccione la rama para restablecerla y haga clic en Ejecutar restablecimiento de Git.

Configurar el modo de checkout parcial

La descarga dispersa es una configuración del lado del cliente que te permite clonar y trabajar solo con un subconjunto de los directorios del repositorio remoto en Azure Databricks. Esto es especialmente útil si el tamaño del repositorio supera los límites admitidos de Azure Databricks.

Habilite el modo checkout disperso al clonar un nuevo repositorio. No se puede desactivar el modo de checkout disperso una vez que se ha habilitado.

1. En el cuadro de diálogo Crear carpeta Git, habilite el modo de extracción dispersa.

   

2. En el cuadro Patrones de cono, especifique los patrones de validación de cono que desee. Separe diferentes patrones por saltos de línea.

Funcionamiento de los patrones de cono

Para comprender cómo funcionan los patrones de cono en el modo de checkout disperso, consulta el siguiente diagrama que representa la estructura del repositorio remoto.

Si selecciona el modo de comprobación dispersa, pero no especifica un patrón de cono, se aplica el patrón de cono predeterminado. Esto incluye solo los archivos en raíz y sin subdirectorios, lo que da como resultado una estructura de repositorio como se indica a continuación:

Al configurar el patrón de cono de extracción dispersa como parent/child/grandchild, se incluye recursivamente todo el contenido del directorio grandchild. También se incluyen los archivos inmediatamente en los directorios /parent, /parent/child y el directorio raíz. Consulte la estructura de los directorios en el diagrama siguiente:

Modificación de la configuración de desprotección dispersa

Después de crear un repositorio, edita el patrón de cono de checkout disperso desde Configuración>Avanzado>Patrones de cono.

Tenga en cuenta el siguiente comportamiento:

• Al quitar una carpeta del patrón de cono, se elimina de Azure Databricks si no hay cambios pendientes.

• Al añadir una carpeta editando el patrón de cono de checkout disperso, esta se añade a Azure Databricks sin necesidad de realizar una operación de pull adicional.

• Los patrones de checkout disperso no se pueden modificar para eliminar una carpeta cuando hay cambios sin confirmar en dicha carpeta.

  Por ejemplo, si edita un archivo en una carpeta y no confirma los cambios, luego intenta cambiar el patrón de checkout disperso para excluir esa carpeta, el patrón se acepta, pero la carpeta no se elimina. Debe revertir el patrón para incluir esa carpeta, confirmar los cambios y volver a aplicar el nuevo patrón.

Realizar cambios con el checkout disperso

Edite los archivos existentes y confirme e insértelos desde la carpeta Git. Al crear nuevas carpetas de archivos, inclúyelas en el patrón de cono que ha especificado para ese repositorio.

La inclusión de una nueva carpeta fuera del patrón de cono produce un error durante la operación de confirmación e inserción. Para solucionarlo, edita el patrón de cono para incluir la nueva carpeta que intentas confirmar y enviar.

Limitaciones del checkout disperso

• El checkout disperso no funciona con repositorios de Azure DevOps de más de 4 GB.
• No puede desactivar el sparse checkout de un repositorio que se creó con el sparse checkout habilitado.

Administración de carpetas de Git mediante programación

Para administrar carpetas de Git mediante la API, consulte la referencia de la API repos.

Eliminación de una carpeta de Git

Para quitar una carpeta git del área de trabajo:

1. Haga clic con el botón derecho en la carpeta Git y seleccione Mover a la papelera.
2. Haga clic en Confirm and move to Trash (Confirmar y mover a la papelera).

Pasos siguientes

• Configure la autenticación para conectar Azure Databricks al proveedor de Git. Consulte Conexión del proveedor de Git a Databricks.
• Obtenga información sobre los límites de tamaño y otras restricciones para las carpetas de Git. Consulte referencias y límites de carpetas de Git de Azure Databricks.
• Configure las opciones de nivel de área de trabajo para la integración de Git. Consulte Configuración de la integración de Git para carpetas de Git.