"Правильный" способ вытащить git "производственная ветка" на производственный сервер
Я довольно новичок в Git и прочитал книгу Pro Git @ http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging. У меня вопрос, является ли то, что я делаю сегодня, предпочтительным способом работы с рабочим сервером и удаленным репозиторием Git.
Мой репозиторий размещен на GitHub с использованием трех удаленных веток: разработка -> тестирование -> мастер.
Всякий раз, когда ветвь 'проверки' была проверена, чтобы работать, я git merge "мастер" с "тестированием" (перемотка вперед?) локально, и git push "мастер" на GitHub.
На производственном сервере (/opt/www/url.com/) я сделал:
git init
git remote add origin https://github.com/.....
git pull origin master
Теперь каждый раз, когда я хочу обновить мастер, я выпускаю git pull
git pull origin master
Производство никогда не будет выдвигать какие-либо изменения на удаленный И локальных изменений не произойдет. Я делаю это правильно? Если нет, какой способ загрузки обновлений предпочтительнее?
Правка № 1: я не хочу управлять какими-либо конфликтами на рабочем сервере, с которыми я сталкиваюсь сейчас (почему-то я сделал что-то не так). Я просто хочу снять последнюю обновленную ветку master и переключиться на нее.
2 ответа
Выполнение "git pull" довольно обычное для этого, но есть более пуленепробиваемый способ.
Не было бы никакого конфликта, если бы вы как-то не внесли локальные изменения. Но если вы просто хотите получить современное дерево и удалить любые локальные изменения, есть лучший способ, который игнорирует все локальное:
Во-первых, вам нужно получить последнюю версию с сервера. Вместо "git pull" для этого мы будем использовать:
git fetch origin master
Это делает первую половину "мерзавца". (Второе - это слияние с вашим локальным мастером, где вы столкнулись с проблемами).
Git fetch делает:
- Находит, на что указывает мастер фиксации на пульте
- Загрузки, которые фиксируют, и все, на что они ссылаются, что у вас нет локально.
- Обновляет исходную / главную ссылку, чтобы указывать на эту фиксацию, чтобы помнить, где удаленный находится в своей версии 'master'.
Далее мы просто обновим наш локальный "master", чтобы он указывал на тот же коммит, и обновим наше рабочее дерево.
Для этого мы будем использовать:
git reset --hard origin/master
(Предполагается, что вы не использовали другое имя для своего удаленного репо вместо стандартного "origin" - измените соответственно, если вы это сделали).
Это на самом деле делает три вещи:
- Обновляет вашу локальную главную ветку так, чтобы она указывала на тот же коммит, который вы только что получили с пульта.
- Загружает это дерево в ваш индекс
- Обновляет ваше рабочее дерево в соответствии с индексом.
Теперь у вас есть локальная основная ветка и дерево, соответствующие удаленному.
Но есть еще один шаг - очистить все, что осталось, это не отслеживается git.
git clean -fdx
Удалит все файлы, созданные предыдущими сборками, и обеспечит чистую среду. В любом случае вы должны копировать любые артефакты сборки, которые хотите сохранить, в другое место.
"Git Pull" предназначен для разработчиков, координирующих их работу, так что это действительно не идеальный инструмент для этой работы. 'git fetch' и 'git reset --hard' более конкретны, без защиты от случайного перезаписи локальной работы.
Но это именно то, что вы хотите здесь.
Тем не менее, если вы иногда вносите изменения для исправления проблем на производственном сервере, вы можете продолжать использовать 'git pull'. Слияния и возможные конфликты могут быть более полезными, чем вредными.
Но иногда вам просто нужно надежное обновление как часть вашей автоматизации, и любые локальные изменения - это проблема, которую нужно устранить.
Но вы, вероятно, хотите, чтобы "git clean" даже с "git pull". Остающиеся файлы могут запутать сборки и развертывания таинственными и трудными для идентификации способами.
Вы должны использовать:
git init --bare
Инициализировать репо, у которого не будет рабочего дерева, что означает отсутствие конфликтов.