git pull конкретна редакція з віддаленого сховища


56

У нас є віддалений gpo repo, який ми зазвичай розгортаємо за допомогою git pushна нашому сервері розробників, а потім git pullна наших живих серверах, щоб отримати останню висунуту версію репо.

Але якщо ми здійснили декілька поправок (без операційних git pullсерверів), як ми можемо зробити це git pull, посилаючись на старіші зобов'язання, які ми хочемо?

тобто щось подібне git pull -r 3ef0dedda699f56dc1062b5dcc2c59f7ad93ede4

Відповіді:


64

Після того, як ви витягнули сховище, ви зможете перейти:

git checkout 3ef0d...

1
Приємно, це спрацювало чудово. Також зауважив, що якщо я хочу повернутися синхронізовано для майбутніх витяг, мені потрібно вказати віддалений сервер під час наступного витягування (тобто git pull server:repoпроти регулярного git pull)
dlrust

1
Можливо, ОП задав неправильне запитання, але для мене це правильне питання, і це не відповідь. На сервері є певна комісія, яка відсутня локально. Команда не є ні гілкою, ні тегом, і вона не переноситься за допомогою потягу / отримання. Як отримати конкретну комісію?
BlackEye

8

uploadpack.allowReachableSHA1InWant

Оскільки Git 2.5.0 цю змінну конфігурації можна ввімкнути на сервері, тут запит на функцію GitHub та GitHub зобов’язання включити цю функцію .

Сервер Bitbucket включив його з версії 5.5+ .

Використання:

# 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"

2

Якщо якийсь процес на вашому живому сервері негайно отримує доступ до щойно витягнутого контенту (тобто ви не можете працювати з git checkout 3ef0dпісля витягування), вам слід розглянути теги версії, яку ви хочете розгорнути у виробництві, і спеціально перевірити цей тег на виробництві, так що витяг не буде негайно змінити робочий каталог. Інакше ви ризикуєте, щоб хтось штовхнувся безпосередньо перед вашим тягненням.


1

Зауважте, що git pull git checkout my-old-commit тепер залишає вас у стані ДЕТЕЧОВАНА ГОЛОВА - фактично ви надсилаєте майбутні зобов’язання у цьому сховищі вниз по новому шляху фіксації. Для repo розгортання це не головне питання, оскільки єдиними комісіями повинні бути ті, які вже зроблені правильно перед тим, як витягнути.

Однак іноді корисно перевірити, чи маркери фіксування (голова, теги, пульти) виглядають ідентичними головним репо. Щоб виправити це після оформлення замовлення: git reset - повторно прив’язує голову git fetch - синхронізує маркери для дистанційних [це може залежати від версії git - правда, наше середовище все ще на 1.7 ... тому більше не потрібно YMMV]

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.