ABF: разблокируем Pull Request

Текущая версия на 08:37, 14 декабря 2016

За годы разработки РОСЫ мы получили тысячи Pull Request’ов от добровольных помощников из сообщества (в частности, запросы на обновление тех или иных программ). Жизненный путь большинства запросов очень прост — разработчик изучает предлагаемые изменения, и если все в порядке, то просто нажимает кнопку Смерджить, после чего нажатием еще одной кнопки отправляет новую версию программы на сборку. Итого — если изменения выглядят корректными, то от разработчика требуется всего два клика мышкой.

Чтобы подобный сценарий был осуществим, необходимо еще одно условие (помимо корректности изменений) — Git-сервер ABF должен быть в состоянии автоматически перенести ваши изменения в репозитории РОСЫ. Понять, так это или нет, очень просто — если сразу после создания запроса он находится в состоянии Готов к мерджу, то все хорошо. Если же он сразу оказался в состоянии Заблокирован, то что-то пошло не так и для принятия ваших изменений разработчикам придется приложить существенно больше усилий, чем пара кликов мышкой. Однако вы можете им помочь, изменив свой проект так, чтобы изменения все-таки можно было перенести автоматически.

Первым делом убедитесь, что вы сделали запрос на изменение в нужную ветку Git-репозитория (ветка соответствует имени платформы — rosa2014.1, rosa2016.1 и так далее).

Если с ветками все в порядке, то причиной блокировки вашего запроса является параллельное внесение изменений в проект другими участниками. Поясним это, рассмотрев типичный процесс подготовки изменений:

1. пользователь создает «форк» проекта, который хочет изменить, в свой репозиторий;
2. пользователь вносит необходимые изменения в свою копию проекта;
3. пользователь создает запрос на изменение (Pull Request) в исходный проект.

Если за время, когда пользователь вносил изменения в свой проект, кто-то изменил исходный проект (например, принял 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.

В завершении хотелось бы призвать наших добровольных помощников не оставлять свои запросы в состоянии "заблокирован", а по возможности вливать изменения, сделанные на стороне РОСЫ. Как ни удивительно, но "разблокировать" запрос со стороны пользователя проще, чем со стороны разработчика.