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 versión. 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.

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

Looker puede configurarse para que funcione con muchos proveedores de Git, como GitHub, GitLab y Bitbucket. Consulta la página de documentación sobre cómo configurar y probar una conexión de Git para obtener información sobre la configuración de Git en tu proyecto de Looker.

Cómo trabajar 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 realizar pruebas sin afectar a otros usuarios. Como desarrollador en Looker, usarás una rama de Git cada vez que estés en el modo de desarrollo.

Otra función importante de Git es la facilidad de colaboración con otros desarrolladores que proporciona. Puedes crear una rama y, si lo deseas, realizar cambios y, luego, otros desarrolladores pueden cambiar a esa rama para revisar o hacer cambios en ella. Si otro desarrollador confirmó cambios en la rama, Looker muestra el botón Extraer cambios remotos. Debes extraer esos cambios confirmados a la rama antes de hacer cambios adicionales.

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

Ramas personales

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

Tu rama personal es específica para ti y no se puede borrar. Tu rama personal es de solo lectura para todos los otros desarrolladores. Si colabora con otros desarrolladores en un proyecto, le recomendamos que cree una rama nueva para que otros puedan cambiar a esa rama y contribuir también con los cambios.

Cómo crear una nueva rama de Git

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

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

  • Si estás trabajando con otros desarrolladores. Dado que tu rama personal es de solo lectura para otros desarrolladores, si deseas colaborar con otras personas, debes crear una nueva rama de Git de modo 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 actualizaciones más recientes de todos los desarrolladores antes de continuar con el trabajo.
  • Trabaja en varios conjuntos de funciones a la vez. A veces, puede estar en medio de un proyecto importante, pero desea 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 separado de funciones. 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, sigue estos pasos:

  • Si tienes un conflicto de combinación en tu rama actual, debes resolver el conflicto antes de crear una rama nueva.
  • Si hay cambios no confirmados en la rama actual, debes confirmar los cambios en la rama actual antes de crear una nueva.
  • Si deseas crear una rama a partir de una rama de desarrollo existente (y no de 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, haz lo siguiente:

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

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

  3. Selecciona el ícono Git en el menú de íconos a la izquierda para abrir el panel Git Actions.

  4. Selecciona el menú desplegable View Branches.

  5. Selecciona New Branch.

  6. En la ventana Rama nueva, ingresa un nombre para tu rama. Tenga en cuenta que existen limitaciones para los nombres de las ramas de Git. Si desea conocer los requisitos para los nombres, consulte las Reglas para nombrar una rama de Git en esta página.

  7. Selecciona el menú desplegable Crear desde y selecciona una rama existente como punto de partida para tu nueva rama.

  8. Selecciona Crear para crear tu rama.

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

Reglas para nombrar una rama de Git

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

Los nombres de las ramas de Git no deben tener las siguientes características:

  • Contienen un carácter de espacio.
  • Contener un punto doble: ..
  • Contener una barra inversa: \
  • Contener 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).
  • Finalizar con una barra diagonal: /
  • Finalizar con la extensión: .lock

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

Cambia a otra rama de Git

Si tienes un conflicto de combinación en tu rama actual, debes resolver el conflicto antes de cambiar a una rama diferente.

Además, si hay cambios no confirmados en la rama actual, no podrás 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 seleccionando el ícono Git en el menú de íconos a la izquierda.
  2. En el panel Git Actions, seleccione el menú desplegable de rama de Git a la derecha del 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 mayúsculas de minúsculas. Por ejemplo, puedes buscar "DEV" y ver todas las ramas con nombres que incluyan "dev", "DEV", "Dev", etcétera.

Administra ramas de Git

La pestaña Branch Management de la página de configuración del proyecto muestra una tabla de todas las ramas de Git para el proyecto de Looker. Para abrir la pestaña Branch Management, primero navega a la página Project Settings. Para ello, selecciona el ícono Settings del menú de la izquierda. Luego, seleccione la pestaña Branch Management.

En la pestaña Branch Management, puedes hacer lo siguiente:

  1. Para crear una rama nueva, selecciona el botón New Branch. Para obtener más información, consulta la sección Crea una nueva rama de Git en esta página.
  2. Busca nombres de ramas en la Barra de búsqueda.
  3. Selecciona el botón Actualizar para actualizar la tabla.
  4. Selecciona un nombre de columna para ordenar la tabla.

La tabla incluye la siguiente información:

  • Nombre: Es el nombre de la rama de Git. Las ramas personales de los desarrolladores de Looker comienzan con dev- e incluyen el nombre y apellido del desarrollador.
  • Status: La diferencia entre tu versión local de la rama y la versión remota de la rama. Por ejemplo, el estado de 3 commits behind significa que la versión local de la rama está detrás de la versión remota de la rama en tres confirmaciones. Como 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 se puede considerar siempre actualizada.
  • Última actualización: Es el tiempo transcurrido 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 borrarla.

Borra ramas de Git

En la pestaña Branch Management, puedes borrar ramas que tienen un botón Delete en la tabla. No puedes borrar las siguientes ramas:

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

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

No puedes restablecer una rama después de borrarla. Cuando borras una rama, Looker quita la versión local de la rama y la versión remota.

Sin embargo, si otro desarrollador de Looker creó la rama, o bien si otros desarrolladores revisaron la rama, esos desarrolladores seguirán teniendo su versión local de la rama. Si un desarrollador de Looker hace una confirmación para su versión local de la rama y la envía a producción, volverás a ver una versión remota de la rama. Esto puede resultar útil si sí quieres restablecer la rama. De lo contrario, cuando borres una rama, todos los demás desarrolladores de Looker deben borrar la misma rama para asegurarse de que alguien que la envíe al control remoto no pueda volver a verla por accidente.

Para borrar una o más ramas de Git de tu proyecto, primero navega a la página Project Settings. Para ello, selecciona el ícono Settings en el menú de íconos a la izquierda. Luego, selecciona la pestaña Branch Management. En la pestaña Branch Management, puedes borrar ramas de dos maneras:

  1. Para borrar varias ramas, primero selecciona las casillas de verificación de las ramas y, luego, Borrar las ramas seleccionadas.
  2. Para borrar una sola rama, selecciona 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. Looker muestra el botón Git en la esquina superior derecha del IDE de LookML.

El botón Git muestra diferentes opciones según la etapa en la que te encuentres para realizar cambios e implementar la producción. En general, la opción que se muestra en el botón es la mejor guía para tu próxima acción.

Si tu rama de desarrollador está sincronizada con la rama de producción, el botón Git muestra el mensaje Up To Date y no se puede seleccionar.

Una vez que tu proyecto esté configurado para Git, puedes seleccionar el botón Git Actions para abrir el panel Git Actions.

Los comandos disponibles en el panel Git Actions dependen de en qué etapa del proceso de realizar cambios y de implementar en producción se encuentren.

Poner los cambios en producción

Con la integración predeterminada de Looker Git, 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 pedirles a tus desarrolladores que envíen solicitudes de extracción para tu rama de producción de Git, en lugar de permitir que combinen sus cambios con el IDE de Looker. Consulta la página de documentación de configuración del control de versión del proyecto para obtener más detalles.
  • Puedes usar el campo Nombre de la rama de producción de Git para especificar qué rama de tu repositorio de Git debe usar Looker como la rama de destino en la que se combinan las ramas de tus desarrolladores de Looker. Consulta la página de documentación de configuración del control de versión del proyecto para obtener más detalles.
  • Puedes usar el modo de implementación avanzada para especificar un SHA de confirmación o un nombre de etiqueta diferente para 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 avanzada webhook o el extremo de la API. Consulta la página de documentación del Modo de implementación avanzada 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 no confirmados

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

Para obtener un resumen de la diferencia de todos los archivos, selecciona la opción View Uncommitted Changes del panel Git Actions.

En la ventana Cambios sin confirmar en el proyecto, Looker muestra un resumen de todos los cambios guardados y 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 reemplazando un archivo nulo (+++ /dev/null).
    • Se muestra que los archivos agregados reemplazan un archivo nulo (--- /dev/null).
  • Es el número de la línea donde comienza el cambio.
    Por ejemplo, -101,4 +101,4 indica que, en la línea 101 del archivo, se quitaron 4 líneas y se agregaron 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 líneas.
  • El texto que se actualizó:
    • Las líneas borradas se muestran en rojo.
    • Las líneas agregadas se muestran en verde.

Para mostrar un resumen de las diferencias de un solo archivo, selecciona Ver cambios en el menú correspondiente.

Cómo confirmar cambios

Después de realizar y guardar cualquier cambio en tu proyecto de LookML, es posible que el IDE requiera que valides tu LookML. En este caso, el botón de Git muestra el texto Validate LookML.

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

Si otro desarrollador realizó cambios en la rama de producción desde la última vez que actualizaste tu rama local, Looker requiere que extraigas esas actualizaciones de la rama de producción. En este caso, el botón de Git muestra el texto Extraer de producción.

Si su proyecto está habilitado para el modo de implementación avanzada, el botón Git mostrará el texto Extraer de la rama principal.

Una vez que guardes los cambios (y corrijas las advertencias o los errores de LookML, si es necesario) y los extraigas de la producción (si es necesario), el botón de Git mostrará el texto Confirmar cambios y enviar.

Si lo deseas, puedes revisar los cambios no confirmados antes de confirmar.

Cuando estés listo para confirmar los cambios, usa el botón Git a fin de confirmarlos en tu rama actual. Looker muestra el cuadro de diálogo Commit, que enumera los archivos que se agregaron, cambiaron o borraron.

Ingresa un mensaje que describa brevemente los cambios y desmarca las casillas de verificación junto a los archivos que no deseas incluir en la sincronización. Luego, selecciona Confirmar para confirmar los cambios.

Cómo buscar PDT sin compilar

Si ha realizado cambios en algún PDT de su proyecto, es óptimo que todas las PDT se compilen cuando se implemente en producción, de modo que las tablas se puedan usar de inmediato como las versiones de producción. Para comprobar el estado de las PDT del proyecto, selecciona el ícono de Estado del proyecto (Project Health) para abrir el panel Estado del proyecto (Project Health) y, luego, haz clic en el botón Validar el estado de la PDT.

Consulte la página de documentación Tablas derivadas en Looker para obtener más información sobre cómo verificar las PDT no compiladas en su 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 la configuración de pruebas de datos en tu proyecto.

Debes estar en el modo de desarrollo para ejecutar pruebas de datos. Una vez que estés en el modo de desarrollo, hay varias formas de iniciar las pruebas de datos de un proyecto:

  1. Si los parámetros de tu proyecto están configurados para exigir pruebas de datos a fin de pasar tus archivos a producción, el IDE presentará el botón Ejecutar pruebas después de que confirmes los cambios en el proyecto para ejecutar todas las pruebas, sin importar qué archivo defina la prueba. Debes pasar las pruebas de datos antes de implementar los cambios en la producción.
  2. Selecciona el botón Run Data Tests en el panel Project Health. Looker ejecutará todas las pruebas de datos de tu proyecto, sin importar qué archivo defina la prueba.
  3. Selecciona la opción Run LookML Tests en el menú del archivo. Looker solo ejecutará las pruebas definidas en el archivo actual.

Una vez que ejecutes las pruebas de datos, el panel Estado del proyecto mostrará el progreso y los resultados.

  • Una prueba de datos se pasa cuando la aserción de la prueba es verdadera para cada fila en la consulta de la prueba. Consulta la página de documentación del parámetro test para obtener detalles sobre la configuración de consultas y aserciones de prueba.
  • 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 del modelo o si la prueba en sí no fue válida.
  • En los resultados de la prueba de datos, puedes seleccionar el nombre de una prueba a fin de ir directamente a LookML para la prueba de datos o puedes seleccionar el botón Explorar consulta a fin de abrir una exploración 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 fusiones 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 avanzada, el IDE te solicitará que combines los cambios con la rama principal. Una vez que combines tu 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 bien mediante 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 pedirá 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 Git, si tienes el permiso deploy, el IDE de Looker te pedirá que combines los cambios con la rama de producción y los implementes en la versión de producción de la instancia de Looker.

Modo de implementación avanzada

Con la integración predeterminada de Looker Git, los desarrolladores de Looker confirman los cambios en la rama de desarrollo y, luego, combinan la rama de desarrollo en la rama de producción. Luego, cuando realices la implementación en el entorno de Looker, este usará la última confirmación en la rama de producción. Consulta la sección Obtén los cambios en la producción en esta página para conocer el flujo de trabajo predeterminado de Git y otras opciones de implementaciones avanzadas de Git.

En los casos en que no desees usar siempre la confirmación más reciente en la rama de producción para tu entorno de Looker, un desarrollador con permiso deploy puede usar el modo de implementación avanzada 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 más desarrolladores o administradores un mayor control sobre los cambios que se implementan en producción.

Cuando se habilita el modo de implementación avanzada, el IDE de Looker no solicita a los desarrolladores que implementen sus cambios en la producción. En cambio, el IDE les solicitará a los desarrolladores que combinen sus cambios en la rama de producción. A partir de allí, los cambios solo se pueden implementar de las siguientes maneras:

  • Mediante Deployment Manager en el IDE de Looker
  • Activa un webhook

  • Con un extremo de API

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

Cómo verificar el impacto de sus cambios

Después de hacer que los cambios estén disponibles para la organización, puedes usar la validación de contenido a fin de asegurarte de no invalidar ningún panel ni guardar las apariencias. Tendrá la oportunidad de corregirlos si es necesario.

Cómo resolver problemas habituales

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

  • Abandona los cambios

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

  • Controla los conflictos de combinación con el trabajo de otros desarrolladores

    Si hay más de un desarrollador trabajando en tu modelo de datos, Git suele manejar la situación. Sin embargo, ocasionalmente Git necesita una persona para resolver conflictos de combinación.

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

Cómo revertir cambios sin confirmar

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

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

  1. Selecciona la opción Revert to... (Revertir a...) en el panel Git Actions.
  2. Seleccione una opción de reversión:
    • Para revertir solo los cambios sin confirmar, selecciona Revertir sin confirmar. También puede seleccionar 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 Revert to Production (Volver a producción).
  3. Para completar el proceso de reversión, selecciona Confirmar.

Para revertir las adiciones o las eliminaciones del contenido de un solo archivo, selecciona la opción Revert Changes en el menú de ese archivo:

Cuando cambias el nombre de 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 Revert to... del panel Git Actions.

Además, si borraste un archivo, 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.

Cómo resolver conflictos de combinación

Por lo general, Git puede combinar automáticamente sus cambios nuevos con la versión de producción de sus archivos LookML. Un conflicto de combinación se produce cuando Git encuentra cambios conflictivos y no puede identificar cuáles deben conservarse, generalmente cuando otro desarrollador realiza cambios desde la última vez que usted realizó el cambio y usted realizó cambios en la misma área. Si tienes un conflicto de combinación en el código, Looker muestra una advertencia de Conflictos de combinación después de que confirmes los cambios y extraigas la producción.

Cuando Looker muestre la advertencia de combinación en conflicto, te recomendamos que resuelvas el conflicto de combinación antes de realizar cualquier otro cambio. Si envías un conflicto de combinación a producción, se producirán errores de análisis que podrían impedir la exploración de tus datos. Si eres usuario de Git avanzado y deseas avanzar con los cambios, selecciona el botón No resolver.

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 combinación para indicar los conflictos de combinación:

  • <<<<<< HEAD marca el comienzo de las líneas en conflicto.
  • >>>>>>> branch 'master' indica el final de las líneas en conflicto.
  • ======= separa cada versión del código para que puedas 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 tus cambios automáticamente.

Para resolver un conflicto de combinación, haz lo siguiente:

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

  3. Guarda el archivo y repite los pasos anteriores para cualquier otro archivo marcado con conflictos de combinación.

  4. Una vez resueltos todos los conflictos de combinación y borrados todos los marcadores de la combinación, confirma los cambios y, luego, impleméntalos en la producción.

Ahora que se resolvió el conflicto de combinación y se envió la resolución a producción, otros desarrolladores pueden realizar la extracción y seguir 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 automáticamente cuando se actualiza o reinicia la instancia de Looker. Para evitar que se ejecute git gc con demasiada frecuencia, Looker espera 30 días desde el último git gc y, luego, ejecuta git gc en el siguiente 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, espera uno o dos minutos y vuelve a intentarlo para aplicar tus cambios.