Gardez le code de votre site dans GitHub
La synchronisation GitHub conserve le code propre à votre site dans un dépôt GitHub, synchronisé dans les deux sens. Chaque version mise en ligne devient un commit dans ce dépôt, et un push vers la branche connectée est vérifié, compilé et publié sur votre site.
Ce qui part vers GitHub
Uniquement les fichiers propres à votre site : ceux que l'explorateur de fichiers affiche et que son téléchargement contient. Les parties partagées sur lesquelles tourne chaque site Briks, les réglages du site, vos clés et les enregistrements de votre base de données n'y vont jamais. Le dépôt ne se construit donc pas et ne s'exécute pas seul : Briks construit et publie ce que vous poussez.
| Dossier | Ce qu'il contient |
|---|---|
app/ | Les pages du site. |
components/custom/ | Les sections écrites pour votre site. |
content/ | Les mots et les faits du site. |
api/ | Le code serveur propre au site, s'il en a. |
db/schema.ts et db/data/ | La structure des données du site et les enregistrements avec lesquels il démarre. |
public/ | Les images et fichiers propres au site. |
Si le dépôt n'a pas de README, Briks en ajoute un qui explique ces dossiers et le fonctionnement de la synchronisation.
Connecter un dépôt
Appuyez sur Connect GitHub
Où : Settings, GitHub
GitHub s'ouvre. Si l'application Briks n'est pas encore sur votre compte ou votre organisation GitHub, GitHub demande où l'installer et quels dépôts elle peut utiliser, puis vous renvoie ici.
Choisissez le dépôt et la branche
Où : Settings, GitHub
Choisissez le compte, puis le dépôt. La branche est d'abord celle par défaut du dépôt ; indiquez-en une autre si vous le souhaitez, et une branche qui n'existe pas encore est créée à partir de la branche par défaut. Create a repository on GitHub ouvre GitHub pour en créer un privé portant le nom de votre site. Repository not listed? Give Briks access to it ouvre les réglages de l'application sur GitHub.
Appuyez sur Connect
Où : Settings, GitHub
Une branche vide est connectée immédiatement. Si la branche contient déjà des fichiers, Briks affiche d'abord combien, lesquels se trouvent dans les dossiers de votre site et ce que son premier commit leur fera. Appuyez sur Connect and commit this site pour continuer, ou sur Choose another.
En quelques minutes, le premier commit apporte votre version en ligne. Il remplace les fichiers des dossiers de votre site par ceux du site et supprime ceux que le site n'a pas. Tout le reste du dépôt demeure tel quel. Rien n'est perdu de son historique, car Briks ne fait jamais de force-push.
De Briks vers GitHub
- Chaque version qui est mise en ligne et modifie les fichiers de votre site devient un commit sur la branche, quelle que soit la façon dont elle a été créée : une génération, une modification, un enregistrement dans le File Explorer ou le Visual Editor, ou une restauration. Pendant qu'un test A/B est en cours, ses versions attendent qu'il se termine.
- Le message du commit est le résumé que vous lisez dans le studio, avec le numéro de la version et le nom de la personne qui l'a demandée.
- GitHub affiche l'état de chaque commit, par exemple Live as version 15.
- Si un fichier contient quelque chose qui ressemble à une clé ou nomme un des services propres à Briks, rien n'est envoyé, et on vous indique de quel fichier il s'agit. Les clés se placent dans Secrets.
De GitHub vers Briks
Un push vers la branche connectée est publié sur votre site, sans IA et sans crédits. Il passe d'abord la même vérification de sécurité qu'un enregistrement dans le File Explorer : un script, un cadre ou un formulaire qui atteindrait un autre site web est refusé, sauf si vous avez ajouté ce site sous Settings, Preferences, Allowed websites. Ensuite Briks le construit, et en une minute ou deux le statut du commit indique Live as version 16, ou pourquoi il n'a pas été publié.
| Ce qu'un push modifie | Ce qui se passe |
|---|---|
Les fichiers de app/, components/custom/, content/, api/, db/schema.ts, db/data/ ou public/ | Publié sur le site. |
Un README, une licence et d'autres fichiers à la racine du dépôt, et .github/ | Conservés sur GitHub. Ils ne font jamais partie du site. |
db/migrations/ | Refusé. Briks écrit les changements des données à partir de db/schema.ts : modifiez donc plutôt le schéma. |
| Les images et autres fichiers qui ne sont pas du texte | Refusé. Ajoutez-les par la bibliothèque de médias. En supprimer un est possible. |
Tout le reste, comme les fichiers de configuration, les fichiers .env ou un fichier qui ressemble à une clé | Refusé, avec la raison indiquée sur le commit. Rien du push n'est publié. |
- Un push peut modifier jusqu'à 300 fichiers, de 256 KB maximum chacun et 8 MB au total.
- Jusqu'à 20 pushes par heure et 100 par jour sont publiés pour chaque site. Un push au-delà de la limite attend, et son statut sur GitHub indique quand il sera publié. Les pushes qui arrivent pendant qu'un autre attend sont publiés ensemble.
- Pendant qu'un test A/B est en cours, un push attend qu'il se termine.
Quand les deux côtés ont modifié le même fichier
Un push qui arrive pendant que Briks publie attend son tour. Si le push et Briks ont modifié des fichiers différents, les deux sont conservés. S'ils ont modifié le même fichier de façon différente, rien du push n'est publié : Briks place sa propre version sur une branche nommée briks-sync, et le statut du push nomme le fichier. Fusionnez briks-sync sur GitHub puis poussez à nouveau, ou réglez cela dans Settings, GitHub :
- Use GitHub's version publie tout le push, y compris le fichier que les deux côtés ont modifié.
- Keep Briks's version publie le push sans les fichiers modifiés des deux côtés.
Si l'historique de la branche est réécrit, par exemple par un force-push, la synchronisation se met en pause jusqu'à ce que vous choisissiez l'un des deux mêmes boutons.
Ce qui vous est indiqué
Les synchronisations réussies restent discrètes, hormis le message indiquant qu'un push est en ligne. Un push non publié, un push en attente de fusion et une connexion interrompue apparaissent dans la cloche, ainsi que dans les chats Telegram et Discord où l'alerte Builds finished or failed est activée. Settings, GitHub affiche les 20 dernières synchronisations dans les deux sens, chacune avec son commit, ses fichiers et son résultat.
Disconnect
- Disconnect dans Settings, GitHub arrête la synchronisation dans les deux sens. Le dépôt et son historique restent exactement tels quels.
- Déplacer le projet vers un autre espace de travail le déconnecte.
- Si l'application est désinstallée sur GitHub, ou si le dépôt est retiré de ses accès, la synchronisation s'arrête et vous en êtes informé.
- Supprimer le projet ne touche jamais au dépôt.
Puis-je démarrer un projet à partir d'un dépôt que j'ai déjà ?
Pas encore. L'import d'un dépôt existant n'est pas disponible. Créez le site dans Briks, puis connectez-lui un dépôt.
Puis-je exécuter le dépôt sur mon propre ordinateur ?
Non. Il contient les fichiers propres à votre site, pas les parties communes sur lesquelles tourne tout site Briks, donc il ne se construit pas seul. Poussez vos modifications, et Briks les construit et les publie.
Que peut faire Briks sur mon compte GitHub ?
Uniquement ce que l'application demande à l'installation : lire et écrire les fichiers des dépôts que vous lui indiquez, et définir le statut des commits. Elle n'écrit que sur la branche que vous avez connectée et, lorsque les deux côtés ont modifié un fichier, sur une branche briks-sync.
Briks lit-il mes messages de commit ?
Non. Le journal de synchronisation affiche le commit de chaque push, ses fichiers et la personne qui l'a envoyé, jamais le message.