Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 11 · Lección

Git folders y flujo de ramas

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 4 de 5

Git folders y flujo de ramas

Git folders permiten ramas, commits y pull requests desde el workspace.

Duración
17 min aprox.
Objetivo
Git folders permiten ramas, commits y pull requests desde el workspace.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Unity Catalog, Git folders y CI/CD esencial

Une gobierno de datos con una entrega de código revisable y promocionable entre entornos.

Al terminar podrás
  • Aplicar el namespace y mínimo privilegio
  • Diferenciar managed, external, volumes y credentials
  • Promover el mismo código con variables por entorno
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Associate + Professional
Ruta relacionada
core
Dominios blueprint
Governance and Security · Implementing CI/CD
Estado
Revisión editorial interna
Fuentes principales
Unity Catalog · ABAC
Reportar un error
04
Diagnóstico

Git folders y flujo de ramas

Git folders permiten ramas, commits y pull requests desde el workspace.

Mostrar prerrequisitos
Dificultad
Associate + Professional
Prerrequisitos
m10
Reportar un error en esta lección

Sincronizan código con Git para colaboración y revisión.

No almacenan tablas ni sustituyen CI; conflictos se resuelven como en un repositorio normal.

Modelo mental

Git folders ofrece una copia de trabajo del repositorio dentro del workspace para ramas, commits, pulls y pushes. Git sigue siendo la fuente de verdad del código; el proveedor aloja pull requests, reglas de revisión y protección de ramas. Una rama representa una línea de cambios, no un ambiente de datos. Los notebooks y archivos se versionan, pero tablas, checkpoints, secretos y resultados de ejecución pertenecen a otras superficies. El flujo profesional crea una rama corta, modifica código y tests, sincroniza, abre pull request y deja que CI valide. Copiar carpetas como final_v2 evita conflictos momentáneamente, pero destruye historial común y hace imposible saber qué versión llegó a producción.

Git folder

Directorio del workspace conectado a un repositorio remoto que permite trabajar con ramas y sincronizar archivos versionados.

Acerca desarrollo al compute sin convertir el workspace en sustituto del historial y gobierno del proveedor Git.
Pull request

Propuesta revisable para integrar commits de una rama, acompañada de diff, checks automáticos y decisiones humanas.

Introduce una frontera de calidad y seguridad antes de que el cambio alcance la rama protegida.
Conflicto de merge

Situación en la que Git no puede decidir automáticamente cómo combinar cambios concurrentes sobre contenido relacionado.

Debe resolverse entendiendo la intención; elegir siempre una versión puede borrar lógica o pruebas válidas.
CLIFlujo conceptual
git checkout -b feature/orders-quality
git add src tests
git commit -m 'Add order quality checks'
git push -u origin feature/orders-quality

La creación del PR ocurre en el proveedor Git.

Puntos clave

  • Código versionado
  • Ramas aíslan cambios
  • PR revisa

Evita

  • Commit de secretos
  • Edición directa en main

Recuerdo activo

¿Dónde se aprueba un PR?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

bundle-examples

bundle-examples · commit c1db792

default_python/src/sample_notebook.ipynb

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
Databricks
Licencia
Databricks License
Formato
bundle
Ver notebook en GitHub