Início / coding / Perguntas / 79486320
Accepted
DekiGembes
Asked: 2025-03-05 19:21:29 +0800 CST

É possível evitar que um arquivo específico seja alterado no branch remoto sem um git force push

  • 772

Compartilhamos um arquivo de build chamado build.sh, que cria um arquivo binário em um caminho específico. Como muitos desenvolvedores alteram o caminho neste arquivo build.sh em seu ambiente local com frequência e esquecem de alterá-lo de volta (queremos manter o caminho de build padrão no arquivo build.sh no branch remoto), um aviso de que um push forçado é necessário para enviar este arquivo para o branch remoto seria ótimo. (às vezes, mas não com frequência, realmente temos que alterar esse arquivo)

.gitignore não é uma opção, pois o arquivo já existe no repositório.

Usamos o bitbucket. Uma solução global seria melhor do que alterar as configurações do git localmente.

Alguma ideia?

Dizer aos desenvolvedores para não usar caminhos individuais certamente ajudaria, mas as pessoas geralmente não seguem isso.

git

3 respostas

  1. build.sh é um script de shell, então faça com que ele carregue a configuração de um arquivo separado:

    if [ -e ./build_custom.sh ]; then
    . ./build_custom.sh
fi

    ou do usuário ~/.build.configou similar. Agora os desenvolvedores podem usar caminhos individuais sem se preocupar com mudanças no script principal.

    • 3
  2. Best Answer

    Você pode configurar um hook pre-receieve . Ele rejeitará pushes onde build.shfoi modificado, a menos que seja um commit explicitamente permitido

    Aqui está a documentação oficial do Bitbucket sobre ganchos de pré-recebimento .

    1. Vá para Configurações do projeto > Ganchos.
    2. Clique em Adicionar gancho
    3. Instalar um gancho personalizado:
    #!/bin/bash
protected_file="build.sh"

while read oldrev newrev refname; do
    if git diff --name-only $oldrev $newrev | grep -q "^$protected_file$"; then
        echo "Error: Modifications to $protected_file are restricted. Please revert your changes before pushing."
        exit 1
    fi
done
exit 0

    Você também pode configurar uma palavra-chave específica [ALLOW_BUILD_CHANGE]para permitir a alteração do seu arquivo protegido:

    while read oldrev newrev refname; do
    if git diff --name-only $oldrev $newrev | grep -q "^$protected_file$"; then
        commit_msg=$(git log --format=%B -n 1 $newrev)
        if ! echo "$commit_msg" | grep -q "\[ALLOW_BUILD_CHANGE\]"; then
            echo "Error: Modifications to $protected_file are restricted. Use '[ALLOW_BUILD_CHANGE]' in commit message to bypass."
            exit 1
        fi
    fi
done

    Observe que esta solução funciona para BitBucket Server e DataCenter

    • 3

  3. Você pode ter um arquivo .env para ambientes locais e .env-prod para produção.

    .env deve estar em .gitignore, o que implica retirá-lo do repositório, para que as pessoas em seus ambientes locais definam seus próprios valores e não enfrentem problemas devido a outros enviando configurações conflitantes.

    E .env-prod deve ser definido somente quando essa for a intenção.

    É claro que você deve evitar o controle de versão de informações confidenciais, pois, se fizer isso, elas estarão tão seguras quanto qualquer pessoa que tenha acesso a elas, incluindo o bitbucket e qualquer pessoa que trabalhe lá, bem como seus scripts...

    • 1

relate perguntas