Implementa y usa el control de versiones

En esta página, se supone que tu proyecto ya se configuró para el control de versión. Si ves un 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 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 para obtener información sobre cómo configurar Git para tu proyecto de Looker.

Trabaja con ramas de Git

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

Otra función importante de Git es la facilidad con la que permite colaborar con otros desarrolladores. Puedes crear una rama y (si lo deseas) hacer cambios. Luego, otros desarrolladores pueden cambiar a esa rama para revisarla o hacerle cambios. Si otro desarrollador confirmó cambios en la rama, Looker mostrará el botón Pull Remote Changes. Debes extraer esos cambios confirmados a la rama antes de realizar cambios adicionales.

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

Ramas personales

Para aumentar el rendimiento, la primera vez que abres un proyecto de LookML en el modo de desarrollo, el IDE de Looker muestra la versión del proyecto en modo de producción, junto con el botón Crear copia para desarrolladores. Una vez que hagas clic en el botón Create Developer Copy del proyecto, el IDE de Looker creará tu rama personal de Git y cargará el proyecto de LookML en el modo de desarrollo.

Tu rama personal comienza con dev- y contiene 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, es posible que desees crear una rama nueva para que otros puedan cambiar a esa rama y también aportar cambios.

Cómo crear una rama de Git nueva

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 y, luego, confirmar los cambios y enviarlos a producción.

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

  • Trabajas con otros desarrolladores. Dado que tu rama personal es de solo lectura para otros desarrolladores, si quieres colaborar con otras personas, debes crear una nueva rama de Git para que otros desarrolladores puedan escribir en ella. Cuando colabores con otras personas, asegúrate de extraer los 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.
  • Estás trabajando en varios conjuntos de funciones a la vez. A veces, es posible que estés en medio de un proyecto importante, pero quieras resolver un problema menor o hacer una corrección rápida. En este caso, puedes confirmar tus cambios en la rama en la que te encuentras y, luego, crear otra rama o cambiar a ella para trabajar en un conjunto de funciones independiente. 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 tienes un conflicto de combinación en tu rama actual, debes resolverlo antes de poder crear una rama nueva.
  • Si tienes cambios sin confirmar en la rama actual, debes confirmar los cambios en la rama actual antes de crear una rama 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 cambiando a esa rama de desarrollo y, luego, extrae los cambios remotos para sincronizar tu versión local de esa rama.

Para crear una rama de Git nueva, haz lo siguiente:

  1. Verifica que tengas activado el modo de desarrollo.

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

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

  4. Selecciona el menú desplegable Ver ramas.

  5. Selecciona Nueva rama.

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

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

  8. Selecciona Crear para crear tu rama.

Como alternativa, puedes crear ramas de Git desde la pestaña Branch Management de la configuración del proyecto.

Reglas para nombrar una rama de Git

Looker usa los requisitos de convención de nomenclatura de ramas especificados por Git.

Los nombres de las ramas de Git no deben cumplir con lo siguiente:

  • Contener un carácter de espacio
  • Contiene un punto doble: ..
  • Contiene una barra inversa: \
  • Contiene la secuencia: @{
  • Contener un signo de interrogación: ?
  • Contiene un corchete de apertura: [
  • Contener un carácter de control ASCII: ~, \^ o :
  • Comienza con un período: .
  • Comienza con el prefijo: dev- (reservado para las ramas personales de los desarrolladores de Looker)
  • Finaliza con una barra diagonal: /
  • Finaliza 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.

Cómo cambiar a otra rama de Git

Si tienes un conflicto de combinación en tu rama actual, debes resolverlo antes de cambiar a otra rama.

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

Para cambiar a otra rama de Git, sigue estos pasos:

  1. En el proyecto, navega al panel Git Actions seleccionando el ícono Git en el menú de íconos de la izquierda.
  2. En el panel Git Actions, selecciona el menú desplegable de la rama de Git a la derecha del nombre de la rama de Git actual.
  3. Selecciona la rama a la que deseas cambiar 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 incluyen "dev", "DEV", "Dev", etcétera.

Administra ramas de Git

En la pestaña Branch Management de la configuración del proyecto, se 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 configuración del proyecto seleccionando el ícono de Settings en el menú de íconos de la izquierda. A continuación, selecciona la pestaña Administración de sucursales.

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

  1. Para crear una rama nueva, selecciona el botón Rama nueva. Consulta la sección Cómo crear una rama de Git nueva en esta página para obtener más información.
  2. Busca nombres de ramas en la barra de búsqueda.
  3. Para actualizar la tabla, selecciona el botón Actualizar.
  4. Para ordenar la tabla, selecciona 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- y contienen el nombre y el apellido del desarrollador.
  • Estado: Es la diferencia entre la 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á tres confirmaciones detrás de la versión remota de la rama. Dado que Looker siempre usa la versión remota de master, la pestaña Branch Management no muestra el estado de la versión local de la rama master. Siempre se puede considerar que la rama principal está actualizada.
  • Last Updated: Es la cantidad de tiempo transcurrido desde que un desarrollador de Looker confirmó un cambio en la rama.
  • Acciones: Un botón para borrar la rama o el motivo por el que la rama no es apta para borrarse.

Cómo borrar ramas de Git

En la pestaña Administración de ramas, puedes borrar las ramas que tengan un 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 un 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 una vez que se borró. Cuando borras una rama, Looker quita tanto la versión local como la remota de la rama.

Sin embargo, si otro desarrollador de Looker creó la rama o si otros desarrolladores la extrajeron, estos seguirán teniendo su versión local de la rama. Si un desarrollador de Looker confirma cambios en 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 ser útil si quieres restablecer la rama. De lo contrario, cuando borres una rama, todos los demás desarrolladores de Looker deberán borrar la misma rama para garantizar que nadie la vuelva a publicar por accidente en el repositorio remoto.

Para borrar una o más ramas de Git de tu proyecto, primero navega a la configuración del proyecto seleccionando el ícono de Configuración en el menú de íconos de la izquierda. Luego, selecciona la pestaña Administración de sucursales. 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, selecciona 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 con tu servicio de Git. Looker muestra el botón de Git en la esquina superior derecha del IDE de LookML.

El botón de Git muestra diferentes opciones según el punto del proceso en el que te encuentres para realizar cambios y realizar la implementación 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 mostrará el mensaje Actualizado y no se podrá seleccionar.

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

Los comandos disponibles en el panel Git Actions dependen de la etapa del proceso en la que te encuentres para realizar cambios y realizar la implementación en producción.

Cómo llevar tus cambios a producción

Con la integración predeterminada de Git de Looker, Looker guía a los desarrolladores a través del 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 los desarrolladores combinen sus cambios a través del IDE de Looker. Consulta la página de documentación 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 combinarán las ramas de tus desarrolladores de Looker. Consulta la página de documentación Configuración del 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 deseas implementar una confirmación de otra rama, puedes usar el modo de implementación avanzado webhook o extremo de API). Consulta la página de documentación del modo de implementación avanzado para obtener más detalles.

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

Cómo ver 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 marcar adiciones, cambios y eliminaciones de la página de documentación de la Descripción general del IDE de Looker.

Para obtener un resumen de las diferencias de todos los archivos, selecciona la opción View Uncommitted Changes en el panel Git Actions.

En la ventana Uncommitted Changes to Project, 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 reemplazos de un archivo nulo (+++ /dev/null).
    • Los archivos agregados se muestran como reemplazos de un archivo nulo (--- /dev/null).
  • 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 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 la opción Ver cambios en el menú del archivo.

Cómo confirmar cambios

Después de realizar y guardar los cambios en tu proyecto de LookML, es posible que el IDE te solicite que valides tu código de LookML. En este caso, el botón Git muestra el texto Validar LookML.

Si esto es obligatorio, depende de 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 Cómo validar tu LookML.

Si otro desarrollador realizó cambios en la rama de producción desde la última vez que actualizaste tu rama local, Looker te solicitará 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 tu proyecto está habilitado para el modo de implementación avanzado, el botón de 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 extraigas de la producción (si es necesario), el botón de Git mostrará el texto Confirmar cambios y enviar.

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

Cuando esté 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 Confirmar, en el que se enumeran los archivos que se agregaron, modificaron o borraron.

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

Cómo verificar si hay PDTs no compiladas

Si realizaste cambios en alguna PDT de tu proyecto, lo ideal es que todas las PDT se compilen cuando implementes la producción para que las tablas se puedan usar de inmediato como versiones de producción. Para verificar el estado de las PDT en el proyecto, selecciona el ícono de Estado del proyecto para abrir el panel Estado del proyecto y, luego, selecciona el botón Validar el estado de las PDT.

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

Ejecuta 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 del parámetro 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 el 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 exigir que se aprueben las pruebas de datos antes de implementar tus archivos en producción, el IDE mostrará el botón Ejecutar pruebas después de que confirmes los cambios en el proyecto para ejecutar todas las pruebas del proyecto, sin importar qué archivo defina la prueba. Debes aprobar las pruebas de datos antes de implementar tus cambios en producción.
  2. Selecciona el botón Ejecutar pruebas de datos en el panel Estado del proyecto. Looker ejecutará todas las pruebas de datos de tu proyecto, independientemente del archivo que 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 aprueba 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 cómo configurar aserciones y consultas de prueba.
  • Si falla una prueba de datos, el panel Estado del proyecto proporcionará información sobre el motivo de la falla, si la prueba encontró errores en la lógica del modelo o si la prueba en sí no era válida.
  • En los resultados de la prueba de datos, puedes seleccionar el nombre de una prueba de datos para ir directamente al LookML de la prueba de datos o seleccionar el botón Explorar consulta para abrir una función Explorar 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 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 tus cambios en la rama principal. Una vez que confirmes tu cambio, un desarrollador de Looker con el permiso deploy podrá implementarlo en producción con 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 con solicitudes de extracción, se te pedirá que abras una solicitud de extracción con la interfaz de tu proveedor de Git.
  • De lo contrario, con la integración predeterminada de Git de Looker, si tienes permiso de deploy, el IDE de Looker te pedirá que combines tus cambios en la rama de producción y que 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 confirman sus cambios en la rama de desarrollo y, luego, la combinan con la rama de producción. Luego, cuando implementas en el entorno de Looker, Looker usa la confirmación más reciente en la rama de producción. (Consulta la sección Cómo llevar tus cambios a producción en esta página para conocer el flujo de trabajo predeterminado de Git y otras opciones para implementaciones avanzadas de Git).

En los casos en los que no quieras que siempre se use la confirmación más reciente en la rama de producción para tu entorno de Looker, un desarrollador con permiso de deploy puede usar el modo de implementación avanzado para especificar la confirmación exacta que se usará para tu entorno de Looker. Esto es útil en los flujos de trabajo de desarrolladores con varios entornos, 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 se habilita el modo de implementación avanzado, el IDE de Looker no les solicita a los desarrolladores que implementen sus cambios en producción. En su lugar, el IDE les solicita a los desarrolladores que combinen sus cambios en la rama de producción. Desde allí, los cambios solo se pueden implementar de las siguientes maneras:

  • Usa el administrador de implementaciones en el IDE de Looker
  • Cómo activar un webhook

  • Usa un extremo de API

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

Cómo verificar el impacto de tus cambios

Después de que los cambios estén disponibles para la organización, puedes usar la validación de contenido para asegurarte de que no se hayan invalidado los paneles ni las Looks guardadas. Si es así, tendrás la oportunidad de corregirlos.

Cómo solucionar problemas típicos

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

  • Descartar los cambios

    En ocasiones, es posible que desees abandonar 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 no confirmados como se describe en la sección Cómo revertir los cambios no confirmados.

  • Manejar conflictos de fusión con el trabajo de otros desarrolladores

    Si tienes más de un desarrollador trabajando en tu modelo de datos, Git suele encargarse de la situación. Sin embargo, en ocasiones, Git necesita que una persona resuelva los conflictos de fusión.

Algunos cambios, como modificar el nombre de un campo, pueden afectar los paneles y Looks 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 verificar tu contenido y solucionar cualquier problema.

Cómo revertir los cambios no confirmados

Cuando trabajes en tu rama de desarrollo personal, puedes revertir los cambios guardados que no se hayan confirmado si no quieres implementarlos. Puedes revertir todos los cambios no confirmados de 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… en el panel Git Actions.
  2. Selecciona una opción para revertir:
    • Para revertir solo los cambios no confirmados, selecciona Revertir los cambios no confirmados. También puedes seleccionar el vínculo Ver cambios para ver los cambios que se revertirían.
    • Para revertir todos los cambios, incluidos los confirmados y los no confirmados, selecciona Revertir a producción.
  3. Para completar el proceso de reversión, selecciona Confirmar.

Para revertir cualquier adición o eliminación en el contenido de un solo archivo, selecciona la opción Revert Changes en el menú de ese archivo:

Cuando cambias el nombre de un archivo, básicamente borras el archivo original y creas uno nuevo con un nombre nuevo. Como esto implica 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… del panel Git Actions.

Además, si borraste un archivo, ya no se mostrará en el navegador de archivos del IDE. Si quieres revertir la eliminación de un archivo, usa la opción Revertir a… del panel Acciones de Git.

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. Se produce un conflicto de combinación cuando Git encuentra cambios en conflicto y no puede identificar qué cambios se deben conservar, por lo general, cuando otro desarrollador realizó cambios desde la última vez que extrajiste 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 confirmar los cambios y extraerlos de la producción.

Cuando Looker muestre la advertencia de conflicto de combinación, te recomendamos que resuelvas el conflicto antes de realizar más cambios. Si envías un conflicto de combinación a producción, se producirán errores de análisis que pueden impedir la exploración de tus datos. Si eres un usuario avanzado de Git y quieres seguir enviando 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 automáticamente tus cambios.

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 bien puedes buscar en tu proyecto marcadores de combinación, como <<<< o HEAD, para encontrar todos los conflictos en tu proyecto. También puedes seleccionar el vínculo files en la advertencia de combinación que aparece en el panel Git Actions para encontrar los archivos afectados.
  2. En el archivo, ve a las líneas con conflictos de combinación, borra la versión del texto que NO quieras conservar y borra también 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. Después de resolver todos los conflictos de combinación y borrar todos los marcadores de combinación de tu proyecto, confirma los cambios y implementa los cambios en producción.

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

Recolección de elementos no utilizados de Git

La recopilación de elementos no utilizados de Git limpia los archivos innecesarios y comprime las revisiones de 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 ejecutar git gc con demasiada frecuencia, Looker espera 30 días desde la última ejecución de git gc y, luego, ejecuta git gc en el siguiente reinicio.

En casos excepcionales, es posible que intentes Push Changes to Remote o Push Branch to Remote mientras se ejecuta git gc. Si Looker muestra un error, espera uno o dos minutos y, luego, vuelve a intentar enviar tus cambios.