Развертывание и сопровождение Redmine правильный путь¶
Настройка локального клона Redmine¶
git clone git@github.com:redmine/redmine.git cd redmine git remote rename origin upstream git remote add origin git@yourserver.com:redmine.git git checkout -b redmine/3.2-stable upstream/3.2-stable git checkout -b local/3.2-stable git push --set-upstream origin local/3.2-stable
Измените номер версии 3.2-stable на номер последней стабильной версии Redmine.
Удаленный репозиторий git@yourserver.com должен быть частным, так как в нем будет храниться конфигурация развертывания (а возможно, и прочая информация, публиковать которую не стоит). Поскольку описанный ниже процесс развертывания будет извлекать из этого репозитория код, то репозиторий должен быть доступен во время развертываний, поэтому не размещайте его на настольных компьютерах. Идеальной будет ситуация, когда репозиторий также будет доступен с веб-сервера, на котором происходит развертывание. Но это при необходимости можно обойти.
Теперь у вас есть две локальные ветви:
redmine/3.2-stable, который отслеживает Redmine 3.2 без дополнительного функционала из репозитория github/redmine, представленная вышеуказанным удаленным восходящим репозиторием,
local/3.2-stable, куда будут помещены все настройки развертывания, кастомизации, темы и плагины.
Пропатчите обновления версий¶
Redmine использует следующую схему нумерации версий: xyz Major/Minor/Patch. Каждая младшая версия имеет собственную стабильную ветку, в которой исправления и патчи безопасности будут применяться с течением времени (до тех пор, пока эта версия все еще поддерживается). В нашем случае это ветвь 3.2-stable.
Время от времени эта восходящая ветвь будет получать некоторые новые коммиты. Ваша задача — включить новые коммиты в локальную ветвь local/3.2-stable для развертывания.
Хотя возможно и просто регулярно дополнять восходящую ветвь, я предлагаю использовать git rebase для поддержки собственного набора изменений поверх стокового кода Redmine:
Перебазирование локальных изменений поверх «голого» Redmine:¶
git checkout redmine/3.2-stable git pull # new upstream commits coming in git checkout local/3.2-stable git rebase redmine/3.2-stable
Команда rebase:
- Отменит все локальные изменения в local/3.2-stable.
- Обновит local/3.2-stable, чтобы отразить изменения, произошедшие в redmine/3.2-stable.
- Повторно применит все локальные изменения поверх «голой» версии.
Итогом будет являться чистая история, в которой ваши (локальные) коммиты всегда находятся поверх последних (восходящих) коммитов Redmine.
Младшие и старшие обновления¶
Теперь, когда есть новая стабильная ветвь (скажем, 3.3-stable), делайте то же самое — перебазируйте ваши изменения поверх неё. Команды git будут немного отличаться из-за изменения восходящей ветви:
Перенос локальных изменений в новую стабильную ветвь¶
git fetch upstream git checkout -b redmine/3.3-stable upstream/3.3-stable git checkout -b local/3.3-stable local/3.2-stable git rebase --onto redmine/3.3-stable redmine/3.2-stable local/3.3-stable
Эти команды вначале создают две новые локальные ветви для версии 3.3: одну из восходящей, а другую — из локальной ветви 3.2. Затем они перебазируют локальные изменения поверх redmine/3.3-stable. Локальные изменения здесь — это разность между redmine/3.2-stable и local/3.3-stable (что по-прежнему является redmine/3.2-stable). Теперь local/3.3-stable содержит Redmine 3.3 плюс любые локальные изменения.
Для новой старшей версии требуется сделать то же самое.
Бог ты мой, у меня конфликты!¶
Рано или поздно (вероятно, уже во время первого обновления до новой младшей версии) вы столкнетесь с конфликтами слияния. Во время ребазирования Git применяет коммиты один за другим и останавливается каждый раз, когда применение коммита происходит с ошибками. В этом случае команда git status покажет проблемные файлы.
Проверьте, какой из коммитов дал сбой, узнайте, для чего он предназначался (хорошо помогут осмысленные сообщения коммитов), исправьте файлы, командой git add добавьте каждый исправленный файл, когда закончите. Если конфликты были устранены, можно просмотреть изменения, которые будут зафиксированы, с помощью команды git diff --cached. Как только вы сочтете результат удовлетворительным, можно продолжить ребазирование с помощью команды git rebase --continue.
Если вы неожиданно получили кучу конфликтов, а времени на решение этой проблемы нет, можно просто прервать текущее ребазирование с помощью параметра --abort, который восстановит рабочую копию до исходного состояния.