Início / server / Perguntas / 117255
Accepted
dlrust
Asked: 2010-02-27 10:26:59 +0800 CST

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

  • 772

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

Mas se nós confirmamos e enviamos algumas revisões (sem um git pullnos servidores ativos), como podemos fazer um git pullque esteja se referindo ao commit mais antigo que queremos?

ou seja, algo comogit pull -r 3ef0dedda699f56dc1062b5dcc2c59f7ad93ede4

git

4 respostas

  1. Best Answer

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

    git checkout 3ef0d...
    • 77

  2. uploadpack.allowReachableSHA1InWant

    Desde o Git 2.5.0 esta variável de configuração pode ser habilitada no servidor, aqui a solicitação de recurso do GitHub e o commit do GitHub habilitando esse 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"
    • 12

  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 3ef0dapós o pull), você deve considerar marcar a versão que deseja implantar na produção e verificar especificamente essa tag na produção, para que o pull não seja imediatamente altere seu diretório de trabalho. Caso contrário, você arriscaria alguém empurrando pouco antes de sua puxada.

    • 2

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

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

    • 1

relate perguntas