Использование Git для обновления производственного сервера

Question

Наша команда недавно перешла на git.

У нас есть рабочий сервер веб-приложений с небольшими изменениями в коде

• Ультра горячие исправления, специфичные для этой установки
• некоторые операторы отладки для тех ошибок, которые не могут быть воспроизведены в нашей среде тестирования

Я думаю, мы не можем зафиксировать их в репо сервера.

Когда мы svn update либо объединили измененный файл, либо не объединили. Теперь

 git stash; git pull; git stash pop

делает трюк для меня

Как автоматически определить случаи, когда git stash pop вызывает конфликты

изготовление рабочей копии сломано?

Я хочу отправить письмо для разрешения этих случаев вручную

до они происходят как be advised, pull cancelled (conflicts)

Answer 1

Я не хотел бы нести риск возникновения конфликта слияния на производственном сервере. Это звучит неправильно для меня.

Из вашего поста я могу сделать вывод, что у вас есть проблемы в производстве, которые вы не можете воспроизвести в ходе тестирования / постановки. Чтобы помочь обнаружить их, вы добавили дополнительные инструменты в свое приложение. Это общий подход, хотя вам действительно следует попытаться воспроизвести сбои в вопросах и ответах (обычно это стоит первоначального удара с точки зрения долгосрочных выгод).

Следующее, что я могу сделать вывод, это то, что вы напрямую манипулируете кодом на рабочем сервере. Вы никогда не должны делать это. Вы уже используете git, который дает вам большую гибкость в управлении вещами, есть более разумные решения вашей проблемы. Вот что я бы сделал:

1. Получить эти изменения с сервера (создать патч или что-то)
2. Поместите эти изменения в локальную ветку вашего репозитория.
3. Всякий раз, когда вы что-то меняете, перебирайте эту локальную ветку поверх головы вашего мастера. Разрешение конфликтов локально.
4. Поскольку вы поэкспериментировали с историей, вам необходимо принудительно запустить рабочий репозиторий, см. Как добавить исправленный коммит в удаленный репозиторий Git? для получения подробной информации.

Также можно обсудить, не хотите ли вы «произвести» добавленную вами дополнительную запись в журнал, сделав ее частью ваших нефункциональных требований.

Answer 2

Я бы предпочел:

• имеет четкое разделение между хранилищем git и веб-файлами:
• не работает напрямую в каталоге рабочего дерева (с проблемой stash, чтобы иметь чистое рабочее дерево для операций извлечения)

Лучше всего перейти к голому репо с хуком после обновления и работать с отдельным репозиторием Git, где вы можете выполнять те операции, которые вам нужны.

---

Как говорится, я бы скорее попытался разрешить любой конфликт во временной ветке (из git stash man page )

 git branch <branchname> [<stash>]

Создает и извлекает новую ветвь с именем <branchname>, начиная с фиксации, при которой изначально был создан <stash>, применяет изменения, записанные в <stash>, к новому рабочему дереву и индексу.
Если это удастся, и <stash> является ссылкой на форму stash@{<revision>}, тогда он отбрасывает <stash>. Если не указано <stash>, применяется последний.

Это полезно, если ветка, в которой вы запустили git stash save, изменилась настолько, что git stash не удалось выполнить из-за конфликтов. Поскольку хранилище применяется поверх коммита, который был HEAD во время запуска git stash, он восстанавливает исходное сохраненное состояние без конфликтов.

Как только конфликты разрешены, эта ветвь может быть объединена с мастером.