git puxe revisão específica do repositório remoto

Question

Temos um repositório remoto remoto que normalmente implantamos usando git push em nosso servidor dev e git pull em nossos servidores ativos para obter a versão mais recente do repositório.

Mas se tivermos confirmado e forçado algumas revisões (sem um git pull nos servidores ativos), como podemos fazer um git pull que esteja se referindo à confirmação mais antiga que queremos?

i.e. algo como git pull -r 3ef0dedda699f56dc1062b5dcc2c59f7ad93ede4

    

Answer 1

Depois de puxar o repositório, você deve poder ir:

git checkout 3ef0d...

    

Answer 2

uploadpack.allowReachableSHA1InWant

Desde Git 2.5.0 , esta variável de configuração pode ser ativada no servidor, aqui a solicitação de recurso do GitHub e o confirmação do GitHub ativando este recurso .

O Bitbucket Server o habilitou desde a versão 5.5+ .

Uso:

# Make remote with 4 commits, and local with just one.
mkdir server
cd server
git init
touch 1
git add 1
git commit -m 1
git clone ./ ../local
for i in {2..4}; do
    touch "$i"
    git add "$i"
    git commit -m "$i"
done

# Before last commit.
SHA3="$(git log --format='%H' --skip=1 -n1)"
# Last commit.
SHA4="$(git log --format='%H' -n1)"

# Failing control without feature.
cd ../local
# Does not give an error, but does not fetch either.
git fetch origin "$SHA3"
# Error.
git checkout "$SHA3"

# Enable the feature.
cd ../server
git config uploadpack.allowReachableSHA1InWant true

# Now it works.
cd ../local
git fetch origin "$SHA3"
git checkout "$SHA3"
# Error.
git checkout "$SHA4"

    

Answer 3

Se algum processo em seu servidor ativo acessar imediatamente o conteúdo recém-puxado (ou seja, você não pode trabalhar com git checkout 3ef0d após pull), considere a marcação da versão que deseja implantar na produção e especificamente verificar essa tag na produção para que puxar não mude imediatamente o seu diretório de trabalho. Caso contrário, você se arriscaria a empurrar alguém antes de sua atração.

    

Answer 4

Note que um %código% agora deixa você em um estado DETACHED HEAD - efetivamente você está enviando futuros commits neste repositório para baixo em um novo caminho de commit. Para um repo de implantação, isso não é um grande problema, já que as únicas confirmações devem ser aquelas já confirmadas corretamente antes de serem obtidas.

No entanto, às vezes é útil verificar se os marcadores de confirmação (head, tags, remotes) são idênticos ao repo master. Para corrigir isso após o checkout: git pull git checkout my-old-commit - recoloca a cabeça git reset - sincroniza os marcadores para controles remotos [isso pode ser dependente da versão do git - reconhecidamente nosso ambiente ainda está em 1.7 ... então pode não ser mais necessário YMMV]