Guarda el código de tu sitio en GitHub

#Qué se envía a GitHub

Solo los archivos propios de tu sitio: los que muestra el Explorador de archivos y los que incluye su descarga. Las partes compartidas sobre las que funciona todo sitio de Briks, los ajustes del sitio, tus claves y los registros de tu base de datos nunca van allí. Por eso el repositorio no se compila ni se ejecuta por sí solo: Briks compila y publica lo que subes.

Si el repositorio no tiene README, Briks añade uno que explica estas carpetas y cómo funciona la sincronización.

#Conecta un repositorio

En un par de minutos, el primer commit trae tu versión en vivo. Reemplaza los archivos de las carpetas de tu sitio por los propios del sitio y elimina los que el sitio no tiene. Todo lo demás del repositorio se queda como está. No se pierde nada de su historial, porque Briks nunca hace force-push.

#De Briks a GitHub

• Cada versión que se publica y cambia los archivos de tu sitio se convierte en un commit en la rama, sin importar cómo se hizo: una compilación, un cambio, un guardado en el File Explorer o en el Visual Editor, o una restauración. Mientras se ejecuta una prueba A/B, sus versiones esperan a que termine.
• El mensaje del commit es el resumen que lees en el estudio, con el número de la versión y el nombre de quien la pidió.
• GitHub muestra el estado de cada commit, como Live as version 15.
• Si un archivo contiene algo con forma de clave o menciona un servicio propio de Briks, no se envía nada y se te indica qué archivo es. Las claves van en Secrets.

#De GitHub a Briks

Un push a la rama conectada se publica en tu sitio, sin IA y sin créditos. Primero pasa la misma comprobación de seguridad que un guardado en el File Explorer: se rechaza un script, un frame o un formulario que llegue a otro sitio web, salvo que hayas añadido ese sitio en Settings, Preferences, Allowed websites. Después Briks lo compila y, en uno o dos minutos, el estado del commit dice Live as version 16, o explica por qué no se publicó.

• Un push puede cambiar hasta 300 archivos, de hasta 256 KB cada uno y 8 MB en total.
• Se publican hasta 20 pushes por hora y 100 al día para cada sitio. Un push que supera el límite espera, y su estado en GitHub indica cuándo se publicará. Los pushes que llegan mientras otro espera se publican juntos.
• Mientras se ejecuta una prueba A/B, un push espera a que termine.

#Cuando ambos lados cambiaron el mismo archivo

Un push que llega mientras Briks está publicando espera su turno. Si el push y Briks cambiaron archivos distintos, se conservan ambos. Si cambiaron el mismo archivo de forma distinta, no se publica nada del push: Briks pone su propia versión en una rama llamada briks-sync, y el estado del push indica el archivo. Fusiona briks-sync en GitHub y vuelve a hacer push, o resuélvelo en Settings, GitHub:

• Use GitHub's version publica todo el push, incluido el archivo que cambiaron ambas partes.
• Keep Briks's version publica el push sin los archivos que cambiaron ambas partes.

Si se reescribe el historial de la rama, por ejemplo con un force-push, la sincronización se pausa hasta que elijas uno de los mismos dos botones.

#Lo que se te avisa

Las sincronizaciones que funcionan son silenciosas, salvo el mensaje de que un push está en vivo. Un push que no se publicó, un push a la espera de una fusión y una conexión que se detuvo aparecen en la campana, y en los chats de Telegram y Discord que tengan activada la alerta Builds finished or failed. Settings, GitHub muestra las últimas 20 sincronizaciones en ambos sentidos, cada una con su commit, sus archivos y su resultado.

#Desconectar

• Disconnect en Settings, GitHub detiene la sincronización en ambos sentidos. El repositorio y su historial quedan exactamente como están.
• Mover el proyecto a otro espacio de trabajo lo desconecta.
• Si la app se desinstala en GitHub, o el repositorio se quita de su acceso, la sincronización se detiene y se te avisa.
• Eliminar el proyecto nunca toca el repositorio.