O primeiro é o plano de fundo quando uso este comando.Depois que o branch local se funde com o branch master (para resolver alguns conflitos antecipadamente), eu envio mr e solicito a fusão do branch local no branch master.
O problema está no commit depois que o branch local se funde com o branch master para resolver o conflito. Como muito conteúdo foi atualizado no branch master, muitos arquivos foram atualizados durante o commit.
O commit do git falhou ao enviar e muitos erros foram relatados. Quando eu vi, todos eram erros de sintaxe eslint e todos eram arquivos atualizados do branch master. Provavelmente eram alguns problemas históricos que sobraram. Neste momento , definitivamente não tive tempo de modificá-los um por um, então tive que contornar os erros.A
sintaxe do eslint é verificada no gancho de pré-confirmação. Aqui está a explicação para isso
Primeiro, vamos conhecer os ganchos do git:
Os ganchos são armazenados no subdiretório hooks do diretório git. Ou seja, .git/hooks na maioria dos projetos. Ao usar git init para inicializar um novo repositório, o git colocará alguns scripts de amostra neste diretório por padrão. Além de serem chamados, esses scripts também revelam os parâmetros passados quando são acionados. Todos os exemplos são scripts shell, alguns com código Perl misturado, mas qualquer script executável nomeado corretamente funcionará.
GIT_DIR/hooks/pre-commit :
Este gancho é chamado pelo comando git commit e pode ser ignorado adicionando o parâmetro –no-verify ao comando. Este gancho não requer parâmetros e é chamado após receber a mensagem de commit e antes de iniciar o commit. Se o valor de retorno do gancho não for 0, o comando git commit abortará a execução.
**Anotação:** Este gancho pode ser usado para verificar erros de código antes do envio (como executar o programa lint).