За годы разработки РОСЫ мы получили тысячи Pull Request’ов от добровольных помощников из сообщества (в частности, запросы на обновление тех или иных программ). Жизненный путь большинства запросов очень прост — разработчик изучает предлагаемые изменения, и если все в порядке, то просто нажимает кнопку Смерджить, после чего нажатием еще одной кнопки отправляет новую версию программы на сборку. Итого — если изменения выглядят корректными, то от разработчика требуется всего два клика мышкой.
Чтобы подобный сценарий был осуществим, необходимо еще одно условие (помимо корректности изменений) — Git-сервер ABF должен быть в состоянии автоматически перенести ваши изменения в репозитории РОСЫ. Понять, так это или нет, очень просто — если сразу после создания запроса он находится в состоянии Готов к мерджу, то все хорошо. Если же он сразу оказался в состоянии Заблокирован, то что-то пошло не так и для принятия ваших изменений разработчикам придется приложить существенно больше усилий, чем пара кликов мышкой. Однако вы можете им помочь, изменив свой проект так, чтобы изменения все-таки можно было перенести автоматически.
Первым делом убедитесь, что вы сделали запрос на изменение в нужную ветку Git-репозитория (ветка соответствует имени платформы — rosa2014.1, rosa2016.1 и так далее).
Если с ветками все в порядке, то причиной блокировки вашего запроса является параллельное внесение изменений в проект другими участниками. Поясним это, рассмотрев типичный процесс подготовки изменений:
Если за время, когда пользователь вносил изменения в свой проект, кто-то изменил исходный проект (например, принял Pull Request от другого пользователя), то с большой вероятностью ABF не сможет автоматически влить изменения. Именно в такой ситуации и получится заблокированный Pull Request. Строго говоря, если вы изменяли одни файлы, а разработчик — другие, то блокировки не будет. Однако специфика сборки rpm-пакетов такова, что при внесении любых изменений вам надо как минимум пересобрать пакет с поднятием версии или релиза, а для этого надо изменить spec-файл. Поэтому 99 % изменений в проекте изменяют и spec-файл, как следствие — почти всегда параллельные изменения приводят к невозможности автоматически их объединить.
Итак, что же делать в такой ситуации?
Удалите свой проект на ABF и повторите весь процесс сначала - форкните исходный проект себе в репозиторий, внесите свои изменения (вы ведь не забыли сохранить локальную копию своего проекта перед его удалением на ABF?) и заново отправьте Pull Request.
Вместо удаления своего проекта вы можете сделать форк исходного с другим именем (при форке проекта вы можете задать любое имя) и в дальнейшем работать с ним.
Такой подход не займет много времени и хорошо подходит для большинства случаев. Однако стоит помнить, что при этом вы потеряете историю собственных изменений. Если эта история вам дорога, то можно воспользоваться альтернативным способом.
ABF выполняет слияние изменений с помощью команды git merge. Блокировка запроса случается в том случае, если эта команда завершается неудачей. Разрешение проблем в такой ситуации требует вмешательства человека; вмешаться в процесс вливания изменений в проект РОСЫ пользователь не может, однако он может проделать процесс в обратном направлении - перенести с помощью Git все изменения из исходного проекта в свой.
Делается это с помощью следующих команд, которые необходимо выполнить внутри директории с клонированным проектом из вашего репозитория (назовем проект foo):
$ abf remote import $ git merge import/<target_branch>
Клиент abf немного облегчает жизнь - то же самое непосредственно с помощью git можно проделать следующим образом:
$ git remote add import https://abf.io/import/<project_name>.git $ git fetch import $ git merge import/<target_branch>
Команда git merge сообщит вам, что в определенных файлах обнаружены конфликты. Вам надо просмотреть каждый из этих файлов и найти места конфликтов, отмеченные разделителями "<<<<" и ">>>>". Каждое из таких мест необходимо отредактировать и привести к тому виду, который они должны иметь с вашей точки зрения. Когда все готово, необходимо закоммитить ваши изменения:
$ git commit <перечень_измененных_файлов> -m "Merge upstream changes" $ git push
После этого можно снова отправлять Pull Request - на сей раз он не должен оказаться заблокированным.
Для тех, кто не хочет ограничиваться формальным знанием нужных "заклинаний", а хочет понять их суть, отсылаем к руководству по системе Git.
В завершении хотелось бы призвать наших добровольных помощников не оставлять свои запросы в состоянии "заблокирован", а по возможности вливать изменения, сделанные на стороне РОСЫ. Как ни удивительно, но "разблокировать" запрос со стороны пользователя проще, чем со стороны разработчика.