Implementa y usa el control de versión

En esta página, se da por sentado que tu proyecto ya se configuró para el control de versión. Si ves el botón Configurar Git en lugar de las opciones descritas en esta página, primero debes configurar Git para tu proyecto.

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.

Looker se puede configurar para que funcione con muchos proveedores de Git, como GitHub, GitLab y Bitbucket. Consulta la página de documentación Configura y prueba una conexión de Git si necesitas información para configurar 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 de Looker, usas una rama de Git siempre que estés en Modo de desarrollo.

Otra característica importante de Git es la facilidad para colaborar con otros desarrolladores que ofrece. Puedes crear una rama y, si lo deseas, realizar cambios. Luego, otros desarrolladores pueden cambiar a esa rama para revisarla o hacer cambios en ella. Si otro desarrollador confirmó cambios en la rama, Looker mostrará el botón Extraer cambios remotos. Debes extraer esos cambios confirmados a la rama antes de realizar cambios adicionales.

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

Ramas personales

La primera vez que accedes al Modo de desarrollo, Looker crea 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 demás desarrolladores. Si colaboras con otros desarrolladores en un proyecto, te recomendamos crear una rama nueva para que otros usuarios puedan cambiar a ella y contribuir con cambios también.

Crea una nueva rama de Git

Si trabajas en un 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 y, luego, 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. Como 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 ella. Cuando colabores con otras personas, asegúrate de realizar cambios cada vez que reanudes el trabajo. De esta manera, tendrás las últimas actualizaciones de todos los desarrolladores antes de seguir trabajando.
  • Estás trabajando en varios conjuntos de funciones a la vez. A veces, puedes estar en medio de un proyecto importante, pero quieres resolver un problema menor o hacer una solución rápida. En este caso, puedes confirmar tus cambios en la rama en la que te encuentras y, luego, crear o cambiar a otra rama para trabajar en un conjunto de funciones separado. Puedes realizar 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 rama nueva, haz lo siguiente:

  • Si hay un conflicto de combinación en tu rama actual, debes resolverlo para poder crear una nueva rama.
  • Si tienes cambios sin confirmar en la rama actual, debes confirmarlos en la rama actual antes de crear una nueva.
  • Si quieres crear una rama a partir de una rama de desarrollo existente (y no de la de producción), primero obtén la versión más reciente de la rama de desarrollo cambiando a esa rama 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ú Develop.

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

  4. Selecciona el menú desplegable View Branches.

  5. Selecciona New Branch.

  6. En la ventana Nueva rama, 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 asignar nombres, consulta las Reglas para nombrar ramas de Git en esta página.

  7. Selecciona el menú desplegable Crear desde y elige una rama existente para usarla como punto de partida para la nueva rama.

  8. Selecciona Crear para crear la 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 nomenclatura de ramas que especifica Git.

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

  • Contener un carácter de espacio
  • Contener un punto doble: ..
  • Contener una barra inversa: \
  • Contiene la secuencia: @{
  • Contener un signo de interrogación: ?
  • Contener un corchete angular de apertura: [
  • Contener 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)
  • Debe terminar con una barra diagonal: /.
  • Termina con la extensión: .lock

Además, el nombre de la rama solo puede incluir 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 real de la rama.

Cambia a otra rama de Git

Si hay un conflicto de combinación en tu rama actual, debes resolverlo antes de cambiar a una rama diferente.

Además, si tienes cambios no confirmados 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 hasta el panel Git Actions. Para ello, selecciona el ícono Git en el menú del ícono de la izquierda.
  2. En el panel Git Actions, selecciona el menú desplegable de la rama de Git a la derecha del nombre actual de tu rama de Git.
  3. Elige la rama a la que quieres cambiar. Para ello, 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", entre otros.

Administra ramas de Git

En la pestaña Administración de ramas de la página Configuración del proyecto, se muestra una tabla con todas las ramas de Git del proyecto de Looker. Para abrir la pestaña Branch Management, primero navega a la página Project Settings seleccionando el ícono Settings en el menú del ícono de la izquierda. Luego, selecciona 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. Consulta la sección Crea una nueva rama de Git en esta página para obtener más información.
  2. Busca nombres de rama en la barra de búsqueda.
  3. Para actualizar la tabla, selecciona el botón Actualizar.
  4. Selecciona el nombre de una columna para ordenar la tabla.

La tabla incluye la siguiente información:

  • Nombre: Indica el nombre de la rama de Git. Las ramas personales de los desarrolladores de Looker comienzan con dev- y, además, 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 mediante tres confirmaciones. Debido a que Looker siempre usa la versión remota de la instancia principal, en la pestaña Administración de ramas no se muestra el estado de la versión local de la rama principal. Puedes considerar que la rama principal siempre está actualizada.
  • Última actualización: Tiempo transcurrido desde que un desarrollador de Looker se comprometió a usar la rama.
  • Acciones: Es un botón para borrar la rama, o bien el motivo por el que no se puede borrar.

Borra ramas de Git

Desde la pestaña Administración de ramas, puedes borrar las ramas que tengan el botón Borrar en la tabla. No puedes borrar las siguientes ramas:

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

En la tabla, estas ramas no tienen el botón Borrar. En cambio, la columna Acción de la tabla 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 tanto tu versión local de la rama como la versión remota de la rama.

Sin embargo, si otro desarrollador de Looker creó la rama, o si otros desarrolladores la consultaron, seguirán teniendo su versión local de la rama. Si un desarrollador de Looker confirma su versión local de la rama y la envía a producción, verás una vez más una versión remota de la rama. Esto puede ser útil si deseas restablecer la rama. De lo contrario, cuando borres una rama, todos los demás desarrolladores de Looker deberían borrarla para garantizar que nadie pueda volver a mostrarla accidentalmente.

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

  1. Para borrar varias ramas, primero selecciona las casillas de verificación de la rama y, luego, selecciona Delete Selected Branches.
  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 tu servicio de Git. Looker muestra el botón Git en la esquina superior derecha del IDE de LookML.

El botón de Git muestra diferentes opciones según el punto en el que te encuentres del proceso de 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 próxima acción.

Si tu rama de desarrollador está sincronizada con la rama de producción, el botón de Git muestra el mensaje Actualizado 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é parte del proceso de implementación de cambios te encuentres en production.

Cómo llevar los cambios a producción

Con la integración predeterminada de Git de Looker, Looker guía a los desarrolladores por 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 de 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 los desarrolladores combinen sus cambios a través del IDE de Looker. Consulta la página de documentación Cómo establecer la configuración de control de versión del proyecto para obtener más detalles.
  • Puedes usar el campo Git Production Branch Name para especificar qué rama de tu repositorio de Git debe usar Looker como la rama de destino en la que se combinan tus ramas de desarrolladores de Looker. Consulta la página de documentación Cómo establecer la configuración de control de versión del proyecto para obtener más detalles.
  • Puedes usar el modo de implementación avanzado para especificar un SHA de confirmación o un nombre de etiqueta diferente para implementar en tu entorno de producción de Looker, en lugar de usar la confirmación más reciente en la rama de producción. Si quieres implementar una confirmación desde una rama diferente, puedes usar el modo de implementación avanzado del webhook o del 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 descritas 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 Modo de desarrollo y tienes cambios sin confirmar, como se describe en la sección Cómo marcar adiciones, cambios y eliminaciones de la página de documentación Edita y valida LookML.

Puedes obtener un resumen de la diferencia de todos los archivos seleccionando la opción View UnConfirmted Changes (Ver cambios no confirmados) del panel Git Actions.

En la ventana UnConfirmar cambios en el proyecto, Looker muestra un resumen de todos los cambios no confirmados y guardados 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, es posible que se muestren 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).
    • Los archivos agregados se muestran como reemplazo de un archivo nulo (--- /dev/null).
  • Es el número de 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. En un archivo borrado con 20 líneas, se 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 que se actualizó tiene las siguientes características:
    • Las líneas borradas se muestran en rojo.
    • Las líneas agregadas se muestran en verde.

Para mostrar un resumen de diferencias en un solo archivo, selecciona 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 proyecto de LookML. El botón de Git muestra el texto Validate LookML en este caso.

Esto depende de la configuración de tu proyecto de calidad del código. Para obtener más información sobre el validador de contenido, consulta la página de documentación 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 de la rama production. El botón de Git muestra el texto Extraer de la producción en este caso.

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

Una vez que guardes los cambios (y corrijas las advertencias o errores de LookML, si es necesario) y extraigas los datos de 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 tengas todo listo para confirmar los cambios, usa el botón de Git para confirmarlos en tu rama actual. Looker muestra el cuadro de diálogo Confirmación, en el que se enumeran los archivos que se agregaron, cambiaron o borraron.

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

Buscando PDT sin compilar

Si modificaste alguna PDT en tu proyecto, lo óptimo es que todas tus PDT se compilen cuando realices la implementación en producción, de modo que las tablas se puedan usar de inmediato como las versiones de producción. Si deseas verificar el estado de las PDT en el proyecto, selecciona el ícono Project Health para abrir el panel Project Health y, luego, selecciona el botón Validate PDT Status.

Consulta la página de documentación de las Tablas derivadas en Looker para obtener más información sobre la verificación de PDT sin compilar 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 uno o más parámetros test que definen pruebas de datos para verificar la lógica de tu modelo de LookML. Consulta la página de documentación de parámetros test para obtener información sobre cómo configurar pruebas de datos en tu proyecto.

Si tu proyecto contiene pruebas de datos y estás en Modo de desarrollo, puedes iniciar las pruebas de datos de tu proyecto de varias maneras:

  1. Si la configuración de tu proyecto está establecida para que se pasen las pruebas de datos antes de implementar tus archivos en producción, el IDE mostrará el botón Run Tests después de confirmar los cambios en el proyecto para ejecutar todas las pruebas, independientemente del archivo que la defina. Debes pasar las pruebas de datos para poder 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, independientemente del archivo que la defina.
  3. Selecciona la opción Run LookML Tests en el menú del archivo. Looker ejecutará solo las pruebas definidas en el archivo actual.

Una vez que ejecutes las pruebas de datos, el panel Project Health mostrará el progreso y los resultados.

  • Una prueba de datos se pasa cuando la aserción de la prueba es verdadera para cada fila de la consulta de la prueba. Consulta la página de documentación del parámetro test para obtener detalles sobre la configuración de aserciones y consultas de prueba.
  • Si falla una prueba de datos, el panel Project Health proporciona información sobre por qué falló la prueba, si esta prueba encontró errores en la lógica del modelo o si fue la prueba en sí que no fue válida.
  • En los resultados de la prueba de datos, puedes seleccionar el nombre de una prueba de datos para ir directamente a LookML de la prueba de datos, o bien seleccionar el botón Explorar consulta para abrir una exploración con la consulta definida en la prueba de datos.

Cómo implementar para producción

Una vez que hayas confirmado los cambios en tu rama, el IDE de Looker te pedirá que combines los cambios en la rama principal. El tipo de instrucción 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 pedirá que combines los cambios en la rama principal. Una vez que combines tu confirmación, un desarrollador de Looker con el permiso deploy puede implementar tu confirmación en producción usando el administrador de implementaciones del IDE de Looker, o con 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 Git de Looker, si tienes el permiso deploy, el IDE de Looker te pedirá que combines los cambios en la rama de producción y los implementes en la versión de producción de tu instancia de Looker.

Modo de implementación avanzada

Con la integración predeterminada de Git de Looker, los desarrolladores de Looker confirman los cambios en su rama de desarrollo y, luego, combinan su rama de desarrollo en la rama de producción. Luego, cuando realices una implementación en el entorno de Looker, Looker usará la confirmación más reciente en la rama de producción. (Consulta la sección Cómo obtener los cambios en producción en esta página para conocer el flujo de trabajo de Git predeterminado y otras opciones para las implementaciones avanzadas de Git).

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

Cuando está habilitado el modo de implementación avanzado, el IDE de Looker no les solicita a los desarrolladores que implementen los 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:

  • Usando deployment Manager en el IDE de Looker
  • Activar un webhook
  • Mediante un extremo de API

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

Cómo comprobar el impacto de los cambios

Después de que los cambios estén disponibles para la organización, puedes usar la validación de contenido para asegurarte de no haber invalidado ningún panel ni vista guardada. Tendrás la oportunidad de corregirlos si es necesario.

Cómo manejar problemas habituales

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

  • Abandona los cambios.

    A veces, es posible que quieras descartar los cambios en el modelado de datos. Si aún no los guardaste, simplemente actualiza la página o sal de ella y, luego, acepta la solicitud de advertencia. Si guardaste los cambios, puedes revertir los cambios no confirmados como se describe en la sección Cómo revertir cambios no confirmados.

  • Cómo controlar los conflictos de combinación con el trabajo de otros desarrolladores

    Si tienes más de un desarrollador trabajando en tu modelo de datos, Git generalmente se encarga de la situación. Sin embargo, a veces, Git necesita una persona para resolver los conflictos de combinación.

Algunos cambios, como modificar el nombre de un campo, pueden afectar los paneles y las vistas 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 para verificarlo y solucionar cualquier problema.

Revertir cambios no confirmados

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

Si quieres revertir los cambios no confirmados para todos los archivos, sigue estos pasos:

  1. Selecciona la opción Revert to... (Revertir a...) en el panel Git Actions (Acciones de Git).
  2. Selecciona una opción de reversión:
    • Para revertir solo los cambios sin confirmar, selecciona Revertir cambios no confirmados. También puedes seleccionar el vínculo Ver cambios para consultar los cambios que se revertirán.
    • Para revertir todos los cambios, incluidos los no confirmados y los confirmados, selecciona Revert to Production
  3. Para completar el proceso de reversión, selecciona Confirmar.

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

Cuando cambias el nombre de un archivo, básicamente se elimina el archivo original y se crea un archivo nuevo con un nombre nuevo. Dado que se trata de más de un archivo, no puedes usar la opción Revert File 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... (Revertir a...) del panel Git Actions.

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

Cómo resolver conflictos de combinación

Por lo general, Git puede combinar automáticamente tus cambios nuevos con la versión de producción de tus archivos de LookML. Un conflicto de combinación se produce cuando Git encuentra cambios conflictivos y no puede identificar qué cambios se deben conservar; por lo general, cuando otro desarrollador realizó cambios desde la última extracción y tú realizaste cambios en la misma área. Si tienes un conflicto de combinación en tu código, Looker mostrará una advertencia de Conflictos de combinación después de que confirmes los cambios y extraigas de producción.

Cuando Looker muestre la advertencia de conflicto de combinación, te recomendamos que lo resuelvas antes de realizar más cambios. Si envías un conflicto de fusión a producción, se generarán errores de análisis que podrían impedir la exploración de tus datos. Si eres un usuario avanzado de Git y quieres realizar 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' marca 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 en el que Git no pudo combinar los 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, o 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 y borra la versión del texto que NO quieras conservar. Además, borra todos los marcadores de conflictos 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 que resuelvas todos los conflictos de combinación y borres todos los marcadores de combinación de tu proyecto, confirma los cambios y, luego, impleméntalos en producción.

Ahora que resolviste el conflicto de fusión y enviaste tu resolución a producción, otros desarrolladores pueden extraer de la 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 los archivos para optimizar tu repositorio de Git. La recolección de elementos no utilizados de Git (git gc) se ejecuta automáticamente cuando se actualiza o reinicia tu 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 próximo reinicio.

En casos excepcionales, puedes intentar Enviar cambios al control remoto o Enviar rama al remoto mientras git gc se está ejecutando. Si Looker muestra un error, espera uno o dos minutos y, luego, vuelve a intentar aplicar los cambios.