Обновление: Похоже, официальная документация проекта OpenERP теперь содержит рекомендации по внесению предложений о слиянии . Я также оставлю свою версию здесь, потому что в ней есть некоторые другие детали.
Поработав несколько дней с Bazaar и Launchpad и представив несколько исправлений и предложений по слиянию, я решил написать краткое изложение того, что нашел. Launchpad и Bazaar предоставляют некоторые мощные инструменты, особенно для проектов, управляемых сообществом, но я не думаю, что новые пользователи, скорее всего, все же попадут в пропасть успеха . Есть несколько способов сделать процесс медленным и разочаровывающим, поэтому я надеюсь, что этот шаг поможет некоторым людям избежать нескольких ошибок.
Вот рабочий процесс, который я изучил, работая над исправлением ошибок и отправкой предложений по слиянию в команду для проекта, размещенного на Launchpad. Я работаю на рабочей станции GNU / Linux, но я предполагаю, что команды Bazaar будут эквивалентны на других платформах. В этом примере я работаю над одним из проектов в группе проектов OpenObject под названием OpenObject Addons. Имя пользователя сопровождающего - openerp. Я помещу свое рабочее пространство в папку ~/workspace.
Если вы хотите узнать больше о любой из команд здесь, используйте bzr help плюс имя команды.
Создать общий репозиторий
Поскольку я собираюсь создавать ветку для каждой функции, которую я хочу внести обратно в проект, я не хочу иметь отдельную копию всей истории проекта для каждой ветви. Чтобы избежать этого, я создаю общий репозиторий, а затем создаю каждую ветку внутри него. Следует соблюдать осторожность, так как формат вашего репозитория должен соответствовать официальному формату ветки, чтобы некоторые последующие шаги работали.
Проверьте формат репозитория в официальной ветке:
bzr info http://bazaar.launchpad.net/~openerp/openobject-addons/5.0
Получить код
Теперь создайте папку рабочей области, которая будет содержать любые локальные ветви на вашем компьютере - я просто назову ее в честь проекта. Затем создайте в нем общий репозиторий в формате, который вы нашли в официальной ветке.
cd ~
mkdir workspace
cd workspace
mkdir openobject-addons
cd openobject-addons
bzr init-repo --format=rich-root-pack .
Следующий шаг - проверить исходный код из официальной ветки. Обычно это называется trunk, но вы можете предпочесть работать со стабильной версией релиза, которая просто используется для исправления ошибок. В этом примере я собираюсь поработать над веткой релиза 5.0.
cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ feature-x
Этот шаг, вероятно, самый медленный во всем процессе для большого проекта, потому что вы копируете весь код плюс всю историю всего проекта на ваш жесткий диск. Обратите внимание, что я называю ветку в честь функции, над которой я собираюсь работать.
Создать ветку
На этом этапе вы можете поэкспериментировать с созданием и запуском кода на локальной рабочей станции. Вы можете вносить изменения в код, но вам пока некуда их фиксировать, потому что вам, вероятно, не разрешено вносить изменения непосредственно в официальную ветку. Чтобы опубликовать изменения кода, вам нужно создать публичную ветку. Если вы новичок в Launchpad, вам нужно создать учетную запись и сначала зарегистрировать открытый ключ .
Как только вы настроите свою учетную запись, вы можете опубликовать свой собственный филиал в качестве копии официального филиала и начать работать с ним. Команда lp-login сообщает bazaar, какое имя учетной записи использовать на сайте панели запуска, а команда whoami сообщает bazaar, какое имя использовать в каждой ревизии, которую вы фиксируете. Адрес электронной почты, который вы используете в whoami, должен совпадать с одним из адресов электронной почты, настроенных для вашей учетной записи Launchpad.
cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <donkirkby@example.com>"
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/feature-x
Вы переключаетесь на новую ветку, чтобы фиксации были записаны в вашей локальной истории и в вашей публичной ветке. Возможно, вы захотите узнать о разнице между оформлением заказа и отделением . Создание этой ветки с накоплением означает, что ее создавать очень быстро, потому что она содержит только историю, которой нет в официальной ветке. Это сообщение в блоге звучит так, как будто ветви общедоступных проектов должны по умолчанию работать в стеке, но это не сработало для меня. Обратите внимание, что я назвал ветку в честь какой-то функции, которую я хочу добавить. Как bialix предложил , я создаю отдельную ветку для каждой функции, которую в конечном итоге предложу объединить с официальной веткой.
Зафиксируйте и сделайте предложение о слиянии
Теперь, когда у вас есть ветка, вы можете вносить изменения в код и фиксировать их.
cd ~/workspace/openobject-addons/feature-x
bzr commit -m "Fixed bug lp:12345 by fleaking the woverbinate() function."
Вы можете коммитить из любой точки в структуре ветки, и она фиксирует всю ветку по умолчанию. Запустите bzr help commit для получения подробной информации. Вы также можете найти bzr status и bzr diff полезными.
Как только вы будете довольны изменениями и передадите все в свою ветку функций, вы можете перейти на веб-сайт Launchpad и создать предложение о слиянии. Вот удобный ярлык, который можно запустить для запуска веб-страницы филиала:
cd ~/workspace/openobject-addons/feature-x
bzr lp-open
Как только вы создадите предложение о слиянии, Launchpad сгенерирует для него diff. Стоит рассмотреть этот дифференциал. Иногда я выбирал не ту ветвь в качестве цели, и я заметил это только потому, что в diff было больше изменений, чем я ожидал. Также есть команда bzr send для предложений по слиянию, но я ее не использовал.
Существует интерфейс электронной почты для отслеживания вашего предложения в процессе, или вы можете просто использовать веб-сайт.
Также полезно прикрепить ветку к ошибке, чтобы другие люди могли использовать ее как патч в своих системах.
текущие изменения
Если вы работаете над несколькими функциями, и сопровождающий не очень быстро просматривает ваши предложения, возможно, стоит создать собственную основную ветку. Эта ветвь собирает все ваши функции вместе и содержит код, который вы запускаете на своих серверах. Это также полезно, если официальная ветвь не очень стабильна, и вы хотите стабилизировать ветку для своей производственной среды. Затем вы можете решить, когда обновляться до последней версии, а когда принимать специальные исправления для ошибок, которые наносят вред вашим пользователям.
Первым шагом является создание еще одной ветки, которая накладывается на официальную ветку:
cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ main
cd main
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/main
Теперь есть два источника изменений, из которых вам нужно слиться. Во-первых, объединение из ветви функций или исправлений:
cd ~/workspace/openobject-addons/main
bzr merge lp:~donkirkby/openobject-addons/feature-x/
bzr commit -m "Merged feature x"
Конечно, если у вас все еще есть локальная копия функциональной ветви, локальное слияние будет быстрее:
cd ~/workspace/openobject-addons/main
bzr merge ../feature-x
bzr commit -m "Merged feature x"
Во-вторых, иногда вы захотите объединить последние и лучшие из официальной ветки:
cd ~/workspace/openobject-addons/main
bzr merge --remember lp:~openerp/openobject-addons/5.0/
bzr commit -m "Merged from 5.0 branch"
После использования --remember при слиянии из официальной ветви вы можете просто использовать bzr merge для слияния из официальной ветви. Если в проекте используются теги для маркировки точек выпуска, вы можете просмотреть список тегов и объединить их из тега.
cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2