Esta página assume que você já vinculou o diretório com
jelou link e baixou os
workflows com jelou pull. Se ainda não fez isso, comece por
Projetos e canais.As duas origens
Seu diretório lê de um único lugar por vez, ejelou status diz qual na
primeira linha.
O rascunho é a origem padrão e é o que o resto da documentação do CLI descreve.
Tudo abaixo é o que muda quando você trabalha em uma branch.
Mudar de origem
jelou checkout <branch> reescreve seus arquivos com o que essa branch serve.
Por isso ele recusa quando você tem edições não publicadas: publique-as antes ou
descarte-as com jelou pull --accept-server.
jelou checkout -b <nome> é a exceção e não toca em nenhum arquivo. Cria a
branch a partir do commit que você está lendo e leva junto seu trabalho em
andamento, então é a forma de dizer “isto que tenho pela metade vai virar uma
branch”.
draft é um nome reservado, para que jelou checkout draft não seja ambíguo.
Você não pode criar uma branch com esse nome.Publicar em uma branch
Estando em uma branch,jelou push muda de significado: em vez de escrever o
rascunho, ele publica um commit e move a branch para ele.
- O rascunho não é tocado. Nada do que você publica em uma branch aparece no Studio até promover para a branch que o Studio lê.
- Só o que mudou é enviado. Os workflows e canais que você não tocou mantêm a versão que a branch já servia, então publicar um arquivo produz um commit completo do mesmo jeito.
- O nome do commit é obrigatório. Use-o para saber o que ele contém quando aparecer no histórico.
Conversas em andamento
Publicar move as conversas que estão pela metade para a versão nova no turno seguinte. Se preferir que terminem na versão com que começaram, publique com--keep-pinned.
master, porque o ajuste é do projeto inteiro e não
de uma branch específica.
Levar o trabalho para outra branch
jelou promote faz outra branch servir o commit em que você está. A promoção
aparece no histórico da branch de destino com seu próprio identificador, e seu
diretório não muda: você continua na sua branch, no seu commit.
O commit do destino recebe um identificador diferente do de origem. É uma cópia,
não o mesmo commit apontado de dois lados, e é por isso que fica registrado no
histórico das duas branches.
--allow-dirty se realmente quiser promover o que foi publicado e deixar suas
edições onde estão.
Qual branch cada canal executa
Isso é independente do que seu diretório lê. Um canal pode estar servindomaster enquanto você trabalha em dev.
master.
set-branch vale imediatamente para conversas novas. Recusa se a branch ainda
não tem nada publicado.
Testar uma branch no número de produção
Apontar o sandbox para a sua branch funciona quando o projeto ainda não tem um número real, ou quando não importa de qual número chegam as mensagens. Quando o que você quer testar é o número que seus clientes já usam,branch-testers
deixa um telefone específico executar a branch enquanto todos os outros
continuam na que o canal serve.
add faz as mesmas verificações de set-branch: o canal deve estar integrado
ao projeto do seu diretório e a branch deve ter algo publicado. Vale a partir da
próxima mensagem desse telefone, e a conversa dele começa do zero na branch.
Registrar o mesmo telefone em outra branch o move.
Com --expires-in <dias> a atribuição termina sozinha; sem ele, dura até você
removê-la com remove. list mostra qual telefone executa qual branch e até
quando.
Para devolver o telefone à branch do canal, remova-o com remove: a partir da
próxima mensagem ele volta a executar o que o canal serve, normalmente master,
como os demais usuários.
O recurso é habilitado por empresa. Se
add responder FORBIDDEN, peça para
ativá-lo na sua; enquanto isso você pode testar a branch no canal de sandbox
como descrito acima. Se o telefone for tester do sandbox do projeto, add também
retira a marca de rascunho dessa atribuição, porque um tester de rascunho executa
o rascunho e nunca chega à branch; ao removê-lo da branch ele continua no que
está publicado, não no rascunho. Um workflow que exista só na branch não é alcançado pela
intenção do usuário, porque o roteamento por intenções é do projeto inteiro;
a versão da branch dos workflows que também existem em master sim é
executada, assim como o workflow padrão.Um ciclo completo
1
Crie a branch e edite
A branch sai do commit que você está lendo e leva junto seu trabalho em
andamento.
2
Publique o primeiro commit
3
Teste em um canal
4
Promova para produção
master serve o mesmo commit que você testou.5
Devolva o canal de testes
Uma branch sem nada publicado
Um projeto novo nasce commaster vazia, e criar uma branch a partir dali é
perfeitamente válido. Seu diretório fica em uma branch sem commits — jelou status chama isso de nothing published yet — e o primeiro jelou push
escreve o commit inicial dela.
Ler uma branch vazia não é um erro. Pedir uma branch que não existe é outra
coisa, e essa sim falha.
O que precisa do rascunho
Estes comandos escrevem o rascunho, então recusam enquanto você lê uma branch. Volte comjelou checkout draft para usá-los.
Depois de um
jelou push em uma branch não há mais nada a executar: o commit
existe e a branch já aponta para ele.
O contrário também vale: jelou promote precisa estar em uma branch, porque o
rascunho não tem nenhum commit para promover.
Workflows em TypeScript
Se você adotou um workflow para TypeScript comjelou workflow adopt, esse
arquivo é a fonte e o CLI nunca escreve JSON por cima, nem ao trocar de branch.
Quando o .ts difere do que a branch serve, jelou pull avisa e jelou status
o marca como modificado. A partir daí você decide:
- Publicar o seu —
jelou push, que o envia como um commit novo. - Ficar com o da branch — apague o
.tse rodejelou pullde novo.