revisión específica de git pull del repositorio remoto

57

Tenemos un repositorio de git remoto que normalmente implementamos desde git pushnuestro servidor de desarrollo y luego git pullen nuestros servidores en vivo para obtener la última versión del repositorio.

Pero si nos hemos comprometido e impulsado algunas revisiones (sin un git pullservidor en vivo), ¿cómo podemos hacer una git pullreferencia al compromiso más antiguo que queremos?

es decir, algo como git pull -r 3ef0dedda699f56dc1062b5dcc2c59f7ad93ede4

git dlrust
fuente

Respuestas:

64

Una vez que haya retirado el repositorio, debería poder ir:

git checkout 3ef0d...
Scott Muc
fuente
1
Bien, esto funcionó perfectamente. También se dio cuenta de que si quiero volver a sincronizarse para futuros tirones necesito especificar el servidor remoto cuando se hace la siguiente tracción (es decir, git pull server:repofrente a los regulares git pull)
dlrust
1
Quizás OP hizo la pregunta incorrecta, pero para mí es la pregunta correcta y esta no es una respuesta. Hay una confirmación específica en el servidor que falta localmente. El commit no es parte de una rama ni de una etiqueta y no se transfiere con un pull / fetch. ¿Cómo obtener una confirmación específica?
BlackEye
8

uploadpack.allowReachableSHA1InWant

Desde Git 2.5.0, esta variable de configuración se puede habilitar en el servidor, aquí la solicitud de la función GitHub y la confirmación de GitHub habilitan esta función .

Bitbucket Server lo habilitó desde la versión 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"
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件
fuente
2

Si algún proceso en su servidor en vivo accede de inmediato al contenido extraído (es decir, no puede trabajar git checkout 3ef0ddespués de extraerlo), debería considerar etiquetar la versión que desea implementar en producción y específicamente retirar esa etiqueta en producción, de modo que la extracción no se realice inmediatamente cambia tu directorio de trabajo. De lo contrario, correría el riesgo de que alguien empuje justo antes de tirar.

Olaf
fuente
1

Tenga en cuenta que un git pull git checkout my-old-commit ahora lo deja en un estado HEAD DESCONECTADO: efectivamente está enviando confirmaciones futuras en este repositorio por una nueva ruta de confirmación. Para un repositorio de implementación, este no es un problema importante, ya que las únicas confirmaciones deben ser las que ya se hayan confirmado correctamente antes de ser retiradas.

Sin embargo, a veces es útil verificar que los marcadores de confirmación (encabezado, etiquetas, controles remotos) se vean idénticos al repositorio principal. Para solucionar esto después de su pago: git reset - vuelve a colocar la cabeza git fetch - sincroniza los marcadores de los controles remotos [esto puede depender de la versión de git - es cierto que nuestro entorno todavía está en 1.7 ... por lo que ya no será necesario YMMV]

Simon Coleman
fuente