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

57

Temos um repositório Git remoto que normalmente implantamos git pushno servidor de desenvolvimento e depois git pullnos servidores ativos para obter a versão mais recente do repositório.

Mas se tivermos confirmado e forçado algumas revisões (sem uma git pullnos servidores ativos), como podemos fazer uma git pullreferência ao compromisso mais antigo que queremos?

ou seja, algo como git pull -r 3ef0dedda699f56dc1062b5dcc2c59f7ad93ede4

git

— dlrust
fonte

64

Depois de extrair o repositório, você poderá:

git checkout 3ef0d...

— Scott Muc
fonte

11

Bom, isso funcionou perfeitamente. Também notei que, se eu quiser voltar à sincronização para futuras solicitações, preciso especificar o servidor remoto ao fazer a próxima git pull server:repogit pull

— solicitação

11

Talvez o OP tenha feito a pergunta errada, mas para mim é a pergunta correta e isso não é resposta. Há uma confirmação específica no servidor que está faltando localmente. O commit não faz parte de uma ramificação nem de uma tag e não é transferido com um pull / fetch. Como buscar um commit específico?

— BlackEye

8

uploadpack.allowReachableSHA1InWant

Desde o Git 2.5.0, essa variável de configuração pode ser ativada no servidor, aqui a solicitação do recurso GitHub e o GitHub confirmam a ativação desse recurso .

O Bitbucket Server o habilitou desde a versão 5.5 ou superior .

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"

— Ciro Santilli adicionou uma nova foto
fonte

2

Se algum processo no servidor ativo acessar imediatamente o conteúdo recém-extraído (por exemplo, você não pode trabalhar com o git checkout 3ef0dpull), considere marcar a versão que você deseja implantar na produção e fazer check-out específico dessa tag na produção, para que o pull não ocorra imediatamente mude seu diretório de trabalho. Caso contrário, você correria o risco de alguém empurrar pouco antes de sua atração.

— Olaf
fonte

1

Observe que a git pull git checkout my-old-commit agora deixa você em um estado DETACHED HEAD - efetivamente você está enviando confirmações futuras neste repositório por um novo caminho de confirmação. Para um repositório de implantação, esse não é um problema importante, pois os únicos confirmados devem ser aqueles já confirmados corretamente antes de serem retirados.

No entanto, às vezes é útil verificar se os marcadores de confirmação (cabeçalho, tags, controles remotos) parecem idênticos ao repositório principal. Para corrigir isso após o checkout: git reset - recoloca o cabeçote git fetch - sincroniza os marcadores para controles remotos [isso pode depender da versão do git - é certo que o nosso ambiente ainda está em 1.7 ... então não é mais necessário YMMV]

— simon coleman
fonte