Usa el control de versión y la implementación

En esta página, se supone que tu proyecto ya se configuró para el control de versiones. Si ves el botón Configurar Git en lugar de las opciones que se describen en esta página, primero debes configurar Git para tu proyecto.

Integración de Git para el control de versiones

Looker usa Git para registrar cambios y administrar versiones de archivos. Cada proyecto de LookML corresponde a un repositorio de Git, y cada rama de desarrollador se correlaciona con una rama de Git. Los repositorios de Git se denominan repositorios.

Looker suele usar GitHub para la administración de archivos fuente de LookML. Sin embargo, Looker se puede configurar para que también funcione con otros proveedores de Git, como GitLab, Bitbucket o cualquier servidor Git que pueda usar una clave SSH para la autenticación.

GitHub no acepta contraseñas de cuentas para autenticar operaciones de Git en github.com. Consulta la entrada de blog de GitHub para obtener más información. Para conectar un proyecto de Looker a GitHub con HTTPS, usa la configuración para desarrolladores en GitHub a fin de crear un token de acceso personal. Para los proyectos de Looker existentes que se conectan a GitHub mediante HTTPS, restablece tu conexión de Git con un token de acceso personal desde GitHub.

Un proyecto de Looker usa solo una cuenta con tu proveedor de Git para todas las interacciones de Git (consulta la página de documentación Integra Looker con Git para obtener información sobre la configuración de Git). Para cada proyecto de Looker, todo el desarrollo de todos los desarrolladores de Looker pasa por esta cuenta de Git. Esto significa que los desarrolladores de Looker no necesitan tener sus propias cuentas con su proveedor de Git, a menos que su instancia de Looker esté configurada con una de las opciones de integración de Git adicionales. En este caso, un desarrollador de Looker necesitará una cuenta de Git para abrir vínculos externos a tu proveedor de Git o crear una solicitud de extracción.

Trabaja con ramas de Git

Uno de los principales beneficios de Git es que un desarrollador de Looker puede trabajar en una rama, una versión aislada de un repositorio de archivos. Puedes desarrollar y probar sin afectar a otros usuarios. Como desarrollador en Looker, usa una rama de Git cada vez que se encuentra en el modo de desarrollo.

Otra característica importante de Git es la facilidad de colaboración con otros desarrolladores que proporciona. Puedes crear una rama y, si lo deseas, hacer cambios y, luego, otros desarrolladores pueden cambiar a esa rama para revisar o cambiar la rama. Si otro desarrollador confirmó los cambios en la rama, Looker mostrará el botón Pull Remote Changes. Debes extraer esos cambios confirmados en la rama antes de realizar cambios adicionales.

También puedes borrar una rama que no sea la rama principal, tu rama actual o una rama personal de un programador.

Sucursales personales

La primera vez que acceda al modo de desarrollo, Looker creará automáticamente su rama de Git personal. Tu rama personal comienza con dev- e incluye tu nombre:

Tu rama personal es específica de ti y no puede borrarse. Tu rama personal es de solo lectura para todos los demás desarrolladores. Si colaboras con otros desarrolladores en un proyecto, te recomendamos crear una rama nueva para que otros puedan cambiar a esa rama y contribuir también con cambios.

SUGERENCIA: No puedes realizar cambios en la rama personal de otro programador. Para seguir trabajando en la rama personal de otra persona, crea una rama nueva a partir de esa rama.

Crea una nueva rama de Git

Si estás trabajando en una solución simple y no colaboras con otros desarrolladores, tu rama personal suele ser un buen lugar para trabajar. Puedes usar tu rama personal para realizar actualizaciones rápidas, confirmar los cambios y enviarlos a producción.

Sin embargo, es posible que también quieras crear nuevas ramas de Git además de tu rama personal. Una nueva rama de Git tiene sentido en estas situaciones:

  • Trabajas con otros desarrolladores. Dado que tu rama personal es de solo lectura para otros desarrolladores, si deseas colaborar con otros, debes crear una nueva rama de Git para que otros desarrolladores puedan escribir en la rama. Cuando colabores con otras personas, asegúrate de hacer cambios cada vez que reanudes el trabajo. De esta manera, tendrás las últimas actualizaciones de todos los desarrolladores antes de continuar con el trabajo.
  • Trabajas en varios conjuntos de funciones a la vez. A veces, puede estar en medio de un proyecto importante, pero quiere resolver un problema menor o hacer una solución rápida. En este caso, puedes confirmar los cambios en la rama en la que te encuentras y, luego, crear o cambiar a otra rama para trabajar en un conjunto de funciones independiente. Puedes hacer la corrección en la rama nueva y, luego, implementar los cambios de esa rama en producción antes de reanudar el trabajo en la rama original.

Antes de crear una nueva rama:

  • Si existe un conflicto de fusión en la rama actual, debes resolver el conflicto antes de crear una rama nueva.
  • Si tienes cambios no confirmados en la rama actual, debes confirmarlos en esa rama antes de crear una nueva.
  • Si deseas crear una rama a partir de una rama de desarrollo existente (y no a la rama de producción), primero obtén la versión más reciente de la rama de desarrollo. Para ello, cambia a esa rama de desarrollo y, luego, extrae los cambios remotos para sincronizar la versión local de esa rama.

Para crear una nueva rama de Git, sigue estos pasos:

  1. Verifica que el modo de desarrollo esté activado.

  2. Navega a los archivos de tu proyecto en el menú Develop.

  3. Haz clic en el ícono Git en el menú de la izquierda para abrir el panel Git Actions.

  4. Haz clic en el menú desplegable Ver ramas.

  5. Selecciona New Branch.

  6. En la ventana Rama nueva, ingresa un nombre para tu rama. Ten en cuenta que existen limitaciones para los nombres de ramas de Git. A fin de conocer los requisitos para nombrarlos, consulta Reglas para asignar nombres a ramas de Git en esta página.

  7. Haga clic en el menú desplegable Crear desde y seleccione una rama existente para usar como punto de partida.

  8. Haz clic en Crear para crear la rama.

Como alternativa, puedes crear ramas de Git en la pestaña Administración de ramas de la página Configuración del proyecto.

Reglas para asignar nombres a una rama de Git

Looker usa los requisitos de convención de nombres de ramas que especifica Git.

Los nombres de ramas de Git no deben hacer lo siguiente:

  • Contiene un carácter de espacio
  • Contiene un punto doble: ..
  • Contener una barra invertida: \
  • Contienen la secuencia: @{
  • Contienen un signo de interrogación: ?
  • Contener un corchete de apertura: [
  • Contienen un carácter de control ASCII: ~, \^ o :.
  • Comienza con un punto: .
  • Comienza con el prefijo: dev- (reservado para las ramas personales de los desarrolladores de Looker)
  • Termina con una barra diagonal: /
  • Finalizar con la extensión: .lock

Además, el nombre de la rama solo puede contener un asterisco (*) si este representa un componente de ruta completo (por ejemplo, foo/* o bar/*/baz), en cuyo caso se interpreta como un comodín y no como parte del nombre de la rama real.

Cambia a otra rama de Git

Si existe un conflicto de fusión en la rama actual, debes resolver el conflicto antes de cambiar a una rama diferente.

Además, si tienes cambios sin confirmar en la rama actual, no puedes cambiar a una rama existente hasta que confirmes los cambios en la rama actual.

Para cambiar a una rama de Git diferente, sigue estos pasos:

  1. En el proyecto, navega al panel Git Actions haciendo clic en el ícono Git en el menú de la izquierda.
  2. En el panel Git Actions, haga clic en el menú desplegable de la rama de Git junto al nombre actual de esa rama.
  3. Para seleccionar la rama a la que deseas cambiar, selecciónala en el menú o escribe el nombre de la rama en el cuadro de búsqueda. La búsqueda de nombres de ramas no distingue entre mayúsculas y minúsculas. Por ejemplo, puedes buscar "DEV" y ver todas las ramas con nombres que incluyen "dev", "DEV" y "Dev", etc.

Administra ramas de Git

La pestaña Branch Management de la página Project Settings muestra una tabla de todas las ramas de Git para el proyecto de Looker. Para abrir la pestaña Branch Management, navega a la página Project Settings. Para ello, haz clic en el ícono Settings del menú de la izquierda y selecciona la pestaña Branch Management.

En la pestaña Administración de ramas, puedes hacer lo siguiente:

  1. Para crear una nueva rama, haz clic en el botón Nueva rama. Consulta la sección Crea una nueva rama de Git en esta página para obtener más información.
  2. Busca nombres de ramas en la barra de búsqueda.
  3. Haz clic en el botón Actualizar para actualizar la tabla.
  4. Para ordenar la tabla, haga clic en el nombre de una columna.

La tabla incluye la siguiente información:

  • Nombre: Nombre de la rama de Git. Las ramas personales de los desarrolladores de Looker comienzan con dev- e incluyen el nombre y el apellido del desarrollador.
  • Estado: La diferencia entre tu versión local de la rama y la versión remota de la rama. Por ejemplo, un estado de 3 commits behind significa que tu versión local de la rama está detrás de la versión remota de la rama en tres confirmaciones. Debido a que Looker siempre usa la versión remota de la instancia principal, la pestaña Branch Management no muestra el estado de la versión local de la rama principal. La rama principal siempre se puede considerar actualizada.
  • Última actualización: La cantidad de tiempo desde que un desarrollador de Looker realizó un compromiso con la rama.
  • Acciones: Un botón para borrar la rama o el motivo por el que la rama no es apta para su eliminación.

Borra ramas de Git

En la pestaña Administración de ramas, puedes borrar ramas que tienen un botón Borrar en la tabla. No puedes borrar las siguientes ramas:

  • La rama principal
  • Su sucursal actual
  • La sucursal personal de un desarrollador de Looker

En la tabla, estas ramas no tienen un botón Eliminar. En cambio, en la columna Acción de la tabla, se muestra el motivo por el que no se puede borrar la rama.

Una vez que se borra una rama, no se puede restablecer. Cuando borras una rama, Looker quita la versión local de la rama y la versión remota de la rama.

Sin embargo, si otro desarrollador de Looker creó la rama o si otros desarrolladores la revisaron, esos desarrolladores seguirán teniendo su versión local de la rama. Si un desarrollador de Looker realiza confirmaciones en su versión local de la rama y la envía a producción, volverá a ver una versión remota de la rama. Esto puede ser útil si sí quieres restablecer la rama. De lo contrario, cuando borras una rama, todos los demás desarrolladores de Looker deben borrar la misma rama para asegurarse de que nadie pueda volver a mostrarla de manera accidental.

Para borrar una o varias ramas de Git de su proyecto, navegue a la página Configuración del proyecto. Para ello, haga clic en el ícono de Configuración del menú de íconos a la izquierda y seleccione la pestaña Administración de ramas. En la pestaña Administración de ramas, puedes borrar ramas de dos maneras:

  1. Para borrar varias ramas, selecciona las casillas de verificación de las ramas y haz clic en Borrar las ramas seleccionadas.
  2. Para borrar una sola rama, haz clic en Borrar junto al nombre de la rama.

Ejecuta comandos de Git en Looker

Looker tiene una interfaz integrada que se integra en su servicio de Git. En el IDE de LookML, verá un botón en la parte superior derecha de Git:

El botón Git muestra diferentes opciones según en qué parte del proceso te encuentres para realizar cambios e implementar en producción. En general, la opción que se muestra en el botón es la mejor guía para tu siguiente acción.

Si tu rama de desarrollador está sincronizada con la rama de producción, verás el mensaje Actualizado:

Una vez que tu proyecto esté configurado para Git, el IDE mostrará el panel Git Actions con comandos de Git adicionales:

Los comandos disponibles en el panel Git Actions dependen de la etapa del proceso en el que se realicen cambios y se implemente en producción.

Obtén los cambios en producción

Con la integración predeterminada de Git con Looker, Looker solicita a los desarrolladores el siguiente flujo de trabajo de Git:

Esto significa que, con la integración predeterminada de Git, todos los desarrolladores combinan sus cambios en una rama llamada master, y la confirmación más reciente en la rama master es la que se usa para el entorno de producción de Looker.

Para implementaciones avanzadas de Git, puedes personalizar este flujo de trabajo:

  • Puedes hacer que tus desarrolladores envíen solicitudes de extracción para tu rama de producción de Git, en lugar de permitir que combinen sus cambios a través del IDE de Looker. Consulta la página de documentación Configura el control de versiones de proyectos para obtener detalles.
  • Puedes usar el campo Git Production Branch Name para especificar qué rama de tu repositorio de Git debe usar Looker como rama de destino en la que se combinan tus ramas de desarrolladores de Looker. Consulta la página de documentación Configura el control de versiones de proyectos para obtener detalles.
  • Puedes usar el modo de implementación avanzado para especificar una confirmación de SHA o un nombre de etiqueta diferentes a fin de implementar en el entorno de producción de Looker, en lugar de usar la confirmación más reciente en la rama de producción. (Si deseas implementar una confirmación desde una rama diferente, puedes usar el modo de implementación avanzado webhook o el extremo de API). Consulta la página de documentación del Modo de implementación avanzado para obtener más detalles.

Si ves el botón Configurar Git en lugar de las opciones que se describen en esta sección, primero debes configurar Git para tu proyecto.

Visualiza los cambios sin confirmar

El IDE de LookML tiene varios indicadores que se muestran cuando estás en modo de desarrollo y tienen cambios sin confirmar, como se describe en la sección Cómo agregar, cambiar y borrar contenido de la página de documentación Cómo editar y validar LookML.

Para obtener un resumen de las diferencias de todos los archivos, usa la opción View Uncommitted Changes del panel Git Actions:

En la ventana Cambios no confirmados en el proyecto, puedes ver un resumen de todos los cambios guardados no confirmados en todos los archivos del proyecto. Para cada cambio, Looker muestra lo siguiente:

  • El nombre del archivo reemplazado y el nombre del archivo agregado.
    • El nombre del archivo reemplazado (indicado con ---) y el nombre del archivo agregado (indicado con +++). En muchos casos, esto puede mostrar diferentes versiones del mismo archivo, con revisiones identificadas por --- a/ y +++ b/.
    • Los archivos borrados se muestran como reemplazo de un archivo nulo (+++ /dev/null).
    • Se muestra que los archivos agregados reemplazan un archivo nulo (--- /dev/null).
  • Es el número de línea en el que comienza el cambio.
    Por ejemplo, -101,4 +101,4 indica que, en la línea 101 del archivo, se quitaron 4 líneas y 4 líneas. Un archivo borrado con 20 líneas mostraría -1,20 +0,0 para indicar que, en la primera línea del archivo, se quitaron 20 líneas y se reemplazaron por cero.
  • El texto se actualizó:
    • Las líneas borradas se muestran en rojo.
    • Las líneas agregadas se muestran en verde.

También puedes obtener un resumen de las diferencias de un solo archivo al seleccionar la opción Ver cambios en el menú del archivo:

Cómo confirmar cambios

Una vez que hayas realizado y guardado los cambios en tu proyecto de LookML, es posible que el IDE requiera que valides tu LookML:

Esto es obligatorio según la configuración de calidad del código del proyecto. Para obtener más información sobre el validador de contenido, consulte la página de documentación de Valida tu LookML.

Si otro desarrollador realizó cambios en la rama production desde la última vez que actualizaste tu rama local, Looker requiere que extraigas esas actualizaciones desde la rama production:

Si tu proyecto está habilitado para el modo de implementación avanzado, este botón dirá Extraer de la rama principal.

Una vez que guardes tus cambios (y corrijas cualquier advertencia o error de LookML, si es necesario) y extraigas datos de producción (si es necesario), el botón Git mostrará el siguiente mensaje:

Si lo deseas, puedes revisar los cambios sin confirmar antes de confirmarlos.

Cuando estés listo para confirmar los cambios, usa el botón Confirmar cambios y enviar para confirmarlos en tu rama actual. Aparecerá la siguiente ventana, donde se mostrarán los archivos que se hayan agregado, modificado o eliminado.

Ingresa un mensaje que describa brevemente los cambios y desmarca los archivos que no deseas incluir en la sincronización. Luego, haz clic en Confirmar para confirmar los cambios.

Buscando PDT sin compilar

Si ha realizado cambios en cualquier PDT de su proyecto, es óptimo que todos sus PDT se compilen cuando realice implementaciones en producción, de modo que las tablas puedan usarse de inmediato como las versiones de producción. Antes de implementar los cambios, puedes verificar si hay PDT no compilados en el proyecto en el panel Estado del proyecto. Haga clic en el ícono de estado del proyecto y, luego, en el botón Validar estado de PDT:

Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre cómo verificar PDT no compilados en tu proyecto de LookML y cómo trabajar con tablas derivadas en modo de desarrollo.

Cómo ejecutar pruebas de datos

Tu proyecto puede incluir pruebas de datos para verificar la lógica de tu modelo de LookML. Consulta la página de documentación del parámetro test para obtener información sobre cómo configurar pruebas de datos en tu proyecto.

Debes estar en modo de desarrollo para ejecutar pruebas de datos. Una vez que te encuentras en el modo de desarrollo, existen varias formas de iniciar pruebas de datos para un proyecto:

  1. Si la configuración de tu proyecto está establecida para requerir que se aprueben las pruebas de datos antes de implementar tus archivos en producción, el IDE presentará el botón Run Tests después de que confirmes los cambios en el proyecto. Se ejecutarán todas las pruebas para tu proyecto, sin importar qué archivo defina la prueba. Debes pasar las pruebas de datos antes de implementar los cambios en la producción.
  2. Haz clic en el botón Run Data Tests en el panel Project Health. Esto ejecutará todas las pruebas de datos en tu proyecto, independientemente del archivo que defina la prueba.
  3. Selecciona la opción Run LookML Tests en el menú del archivo. Esta acción solo ejecutará las pruebas definidas en el archivo actual.

Una vez que ejecute las pruebas de datos, el panel Estado del proyecto le mostrará el progreso y los resultados:

  • Se pasa una prueba de datos cuando la aserción de la prueba es verdadera para cada fila en la consulta de prueba. Consulta la página de documentación del parámetro test para obtener detalles sobre cómo configurar aserciones de prueba y consultas.
  • Si una prueba de datos falla, el panel Estado del proyecto proporcionará información sobre por qué falló la prueba, si la prueba encontró errores en la lógica de tu modelo o si la prueba en sí no fue válida.
  • Desde los resultados de la prueba de datos, puede hacer clic en el nombre de una prueba de datos para ir directamente a la herramienta de búsqueda de datos de la prueba. También puede hacer clic en el botón Explorar consulta para abrir la función Explorar con la consulta definida en la prueba de datos.

Cómo implementar para producción

Una vez que confirmes los cambios en tu rama, el IDE de Looker te pedirá que los combines con la rama principal. El tipo de mensaje que verás en el IDE dependerá de la configuración de tu proyecto:

  • Si tu proyecto está configurado para el modo de implementación avanzado, el IDE te pedirá que combines los cambios con la rama principal. Una vez que fusionas la confirmación, un desarrollador de Looker con el permiso deploy puede implementarla en producción mediante el administrador de implementaciones del IDE de Looker o un webhook o un extremo de API.
  • Si tu proyecto está configurado para la integración de Git mediante solicitudes de extracción, se te solicitará que abras una solicitud de extracción mediante la interfaz de tu proveedor de Git.
  • De lo contrario, con la integración predeterminada de Looker para Git, si tiene el permiso deploy, el IDE de Looker le pedirá que combine sus cambios en la rama production y los implementará en la versión de producción de su instancia de Looker.

Modo de implementación avanzado

Con la integración predeterminada de Looker para Git, los desarrolladores de Looker confirman los cambios en la rama de desarrollo y, luego, la combinan en la rama de producción. Luego, cuando implemente en el entorno de Looker, Looker usará la confirmación más reciente en la rama production. (Consulta la sección Obtén los cambios en la producción en esta página para ver el flujo de trabajo predeterminado de Git y otras opciones para las implementaciones avanzadas de Git).

Para los casos en los que no quieras usar siempre la última confirmación en la rama de producción para tu entorno de Looker, un desarrollador con permiso deploy puede usar el modo de implementación avanzado a fin de especificar la confirmación exacta que se usará en tu entorno de Looker. Esto es útil en flujos de trabajo de desarrolladores de múltiples entornos, en los que cada entorno apunta a una versión diferente de una base de código. También otorga a uno o varios desarrolladores o administradores mayor control sobre los cambios que se implementan en producción.

Cuando el modo de implementación avanzado está habilitado, el IDE de Looker no les pide a los desarrolladores que implementen sus cambios en la producción. En cambio, el IDE solicita a los desarrolladores que combinen sus cambios en la rama production. Desde allí, los cambios solo se pueden implementar de las siguientes maneras:

Consulta la página de documentación del Modo de implementación avanzado para obtener más detalles.

Cómo comprobar el impacto de sus cambios

Una vez que los cambios estén disponibles para la organización, puedes usar la validación de contenido para asegurarte de no invalidar ningún panel ni de guardar aspectos. Si es así, tendrás la oportunidad de corregirlos.

Soluciona problemas típicos

Mientras trabajas en tu modelo, es posible que debas hacer lo siguiente:

  • Abandona tus cambios

    En ocasiones, es posible que quiera abandonar sus cambios en el modelado de datos. Si aún no se guardaron, puede actualizar la página o salir de ella y, luego, aceptar el mensaje de advertencia. Si guardaste los cambios, puedes revertir los cambios no confirmados como se describe en la sección Cómo revertir cambios sin confirmar.

  • Controla los conflictos de fusión con otros desarrolladores (trabajo)

    Si hay más de un desarrollador trabajando en tu modelo de datos, Git suele manejar la situación. Sin embargo, en ocasiones, Git necesita un ser humano para resolver los conflictos de fusión.

Algunos cambios, como cambiar el nombre de un campo, pueden afectar a los paneles y la apariencia existentes. Como se mencionó anteriormente, después de hacer que los cambios estén disponibles para la organización, puedes usar la validación de contenido para verificar el contenido y corregir cualquier problema.

Revertir los cambios no confirmados

Cuando trabajas en tu rama de desarrollo personal, puedes revertir los cambios no confirmados que guardaste si no quieres implementarlos. Puedes revertir todos los cambios no confirmados para todos los archivos del proyecto o solo los cambios en un solo archivo.

Para revertir los cambios no confirmados de todos los archivos, haz lo siguiente:

  1. Haz clic en la opción Volver a... en el panel Git Actions.
  2. Selecciona una opción para revertir:
    • Para revertir solo los cambios sin confirmar, selecciona Revertir cambios no confirmados. También puede hacer clic en el vínculo Ver cambios para ver los cambios que se revertirán.
    • Para revertir todos los cambios, incluidos los no confirmados y los confirmados, selecciona Volver a producción.
  3. Para completar la reversión, haga clic en Confirmar.

Para deshacer cambios en el contenido de un archivo único o eliminarlos, seleccione la opción Deshacer cambios en el menú correspondiente:

Cuando renombras un archivo, lo que haces es borrar el archivo original y crear uno nuevo con un nombre nuevo. Como esto implica más de un archivo, no puedes usar la opción Revertir archivo para deshacer el cambio de nombre de un archivo. Si quieres deshacer el cambio de nombre de un archivo, usa la opción Volver a... del panel Acciones de Git.

Además, si borraste un archivo, este ya no se muestra en el navegador de archivos IDE. Si quieres revertir la eliminación de un archivo, usa la opción Revert to... del panel Git Actions.

Resolución de conflictos de fusión

Por lo general, Git puede combinar automáticamente tus cambios nuevos con la versión de producción de tus archivos LookML. Un conflicto de combinación se produce cuando Git tiene problemas para determinar qué cambios conservar. Por lo general, esto ocurre cuando otro desarrollador realiza cambios desde la última vez que usted realizó la acción y usted hizo cambios en la misma área. Si tienes un conflicto de combinación en el código, recibirás una advertencia en Looker después de confirmar los cambios y extraerlos de la producción:

Cuando Looker muestra la advertencia de combinación de conflictos, se recomienda que resuelvas el conflicto de combinación antes de realizar más cambios. Enviar un conflicto de fusión a producción provocará errores de análisis que podrían impedir la exploración de sus datos. Si eres un usuario avanzado de Git y quieres avanzar con los cambios, haz clic en el botón Don't Resolve.

En el archivo LookML, las líneas con conflictos se marcan de la siguiente manera:

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker muestra los siguientes marcadores de fusión para indicar los conflictos de fusión:

  • <<<<<< HEAD marca el comienzo de las líneas en conflicto.
  • >>>>>> branch 'master' marca el final de las líneas en conflicto.
  • ======= separa cada versión del código para que pueda compararlas.

En el ejemplo anterior, your code representa los cambios que confirmaste y production code representa el código con el que Git no pudo combinar automáticamente tus cambios.

Para resolver un conflicto de combinación:

  1. Busca los archivos con conflictos de fusión. Looker marca estos archivos en rojo o también puede buscar en su proyecto marcadores de fusión, como <<<< o HEAD, para encontrar todos los conflictos en su proyecto. También puedes encontrar los archivos afectados si haces clic en el vínculo archivos en la advertencia de combinación que aparece en el panel Acciones de Git.
  2. En el archivo, ve a las líneas con conflictos de combinación y borra la versión del texto que NO quieres conservar y también borra todos los marcadores de conflicto de combinación.

  3. Guarda el archivo y repite los pasos anteriores para los demás archivos marcados con conflictos de fusión.

    SUGERENCIA: Busca en tu proyecto cada uno de los marcadores de combinación para verificar que se hayan resuelto todos los conflictos y los hayas eliminado. Asegúrate de quitar todas las instancias de marcadores de combinación de tus archivos LookML. Estos marcadores generarán errores de análisis que pueden impedir que los usuarios exploren tus datos.

  4. Una vez que hayas resuelto todos los conflictos y hayas borrado todos los marcadores de combinación de tu proyecto, confirma los cambios y, luego, impleméntalos en la producción.

Ahora que resolviste el conflicto de combinación y enviaste tu resolución a producción, otros desarrolladores pueden realizar extracciones de producción y continuar trabajando como de costumbre.

Recolección de elementos no utilizados de Git

La recolección de elementos no utilizados de Git limpia los archivos innecesarios y comprime las revisiones de archivos para optimizar el repositorio de Git. La recolección de elementos no utilizados de Git (git gc) se ejecuta de forma automática cuando tu instancia de Looker se actualiza o se reinicia. Para evitar que git gc se ejecute con demasiada frecuencia, Looker espera 30 días desde el último git gc y, luego, ejecuta git gc en el próximo reinicio.

En casos excepcionales, puedes intentar Enviar cambios al control remoto o Enviar rama al control remoto mientras git gc se está ejecutando. Si Looker muestra un error, espere uno o dos minutos y vuelva a intentarlo para aplicar sus cambios.