Jump to main content Jump to doc navigation

Чтобы облегчить совместную разработку исходного кода MODX, управляемого на GitHub, была принята четкая и последовательная стратегия ветвления. Эта стратегия состоит в том, чтобы поддерживать ветку основной версии, например, 2.x, который представляет работу, которая будет включена в "следующий значимый выпуск". Если текущий стабильный выпуск версии 2 - 2.2.1, работа в ветке 2.x будет включать работу, предназначенную для выпуска 2.3.0.

Кроме того, существует ветка для текущего стабильного минорного выпуска каждой мажорной версии. Если это 2.2, то ветвь будет 2.2.x. Это будет представлять собой разработку, предназначенную для следующего выпуска патча 2.2. После семантического управления версиями только временные исправления будут нацелены на эти временные второстепенные ветки.

Ветвь мажорной версии

Ветвь мажорной версии, например 2.x и 3.x - это, по сути, виртуальная ветка master для каждого основного выпуска MODX Revolution. Эта ветвь имеет бесконечный срок службы и содержит новые функции, которые не нарушают обратную совместимость, предназначенную для следующего вспомогательного выпуска. Вы можете думать об этом как о «ветви интеграции», где все изменения будут представлены в следующем значимом выпуске.

Когда код в этих ветвях достигает стабильной точки и готов к выпуску, коммит помечается новым второстепенным номером выпуска, например, v2.2.0, и релиз создается из этого тега.

Минорные версии веток

В нашем процессе поддерживаются временные ветки, которые используются для совместной разработки исправлений и обновлений переводов, которые могут быть быстро применены к выпускам патчей. Эти ветви называются ветвями второстепенной версии и имеют ограниченный срок действия, если их родительский минорный выпуск является текущим стабильным выпуском. Они содержат только исправления ошибок и обновления переводов. Следуя правилам семантического управления версиями, новые функции, которые не нарушают обратную совместимость, должны появиться в следующем дополнительном выпуске, никогда в ветке с минорной версией, из которой будут производиться релизы патчей.

Работа с вашим форком GitHub

Участники MODX должны работать напрямую со своими приватными форками на GitHub. Вот предлагаемый способ подготовить ваш локальный репозиторий в качестве разработчика для участия в любом проекте MODX:

git clone git@github.com:YourGitUsername/revolution.git
cd revolution
git remote add upstream -f https://github.com/modxcms/revolution.git

Эта настройка делает ваш форк стандартным origin удаленным и добавляет/извлекает "благословенный" репозиторий как удаленный upstream. Возможно, вы захотите добавить другие ремоты в другие ветки разработчика, и я бы назвал эти ремоты соответствующим образом, чтобы вы могли отслеживать каждый из них.

Вы захотите пойти дальше и создать локальные ветви отслеживания для ветви основной версии и/или ветви вспомогательной версии, с которой вы хотите работать, из своего форка, a.k.a. origin:

git checkout -b 2.x origin/2.x
git checkout -b 2.4.x origin/2.4.x

Чтобы ваши локальные ветви отслеживания для 2.x и 2.4.x были актуальными из репозитория upstream:

git fetch upstream
git checkout 2.4.x
git merge --ff-only upstream/2.4.x
git checkout 2.x
git merge --ff-only upstream/2.x
git push origin 2.4.x 2.x

Тем не менее, обратите внимание, что push предназначен главным образом для показа, так как постоянные ветви никогда не должны быть целью коммитов участника, даже в форках. 2.4.x и 2.x в вашей ветке должны соответствовать ветвям upstream с тем же именем. Ожидается, что все вклады будут отправлены через отдельную ветвь, происходящую из соответствующей современной ветки основной версии, или ветку с исправлением ошибок, происходящую из ветви минорной версии в вышестоящем репозитории.

Также обратите внимание, что флаг --ff-only гарантирует, что будут выполняться только быстрые слияния (в случае, если вы случайно сделаете коммит с ветвями основной или вспомогательной версии на вашем форке, не осознавая этого).

Важно

Пожалуйста, убедитесь, что у вас правильно настроены параметры autocrlf, прежде чем делать какие-либо коммиты на ваш форк. См. http://help.github.com/dealing-with-lineendings/, чтобы определить необходимые настройки в зависимости от платформы, на которой вы разрабатываете.

Feature branches

  • Майская ветка от: major-version ветки
  • Соглашение об именах: полностью зависит от вас

Feature branches, также известные как разделы тем, используются для разработки конкретной новой функции (или набора функций) для будущего выпуска. Как только оно будет принято и готово для включения в следующий дополнительный выпуск, оно будет объединено с основной версией интегратором. Если функция никогда не завершена или не принята, ее можно просто отказаться.

Feature branches существуют в ветвях разработчика, а не в «благословенном» или upstream хранилище.

Создание feature branch

Когда вы начнете работать с новой функцией, отойдите от основной ветки, на которую вы нацелены, например, 2.x.

$ git checkout -b my-bc-feature 2.x
Switched to a new branch "my-bc-feature"

Отправка pull request на получение готовой функции

После того, как вы завершили разработку функции в своей ветке, вы должны сначала убедиться, что ваша работа воспроизводится поверх последних обновлений от develop:

git fetch upstream
git checkout 2.x
git merge --ff-only upstream/2.x
git checkout my-bc-feature
git rebase 2.x

Это поможет интеграторам без труда включать вашу работу.

Теперь просто перенесите свою функцию в свой форк (вы можете сделать это на ранней стадии, если вы хотите поделиться своей веткой функций для совместной работы или обзора):

git push origin my-bc-feature

И вы готовы отправка pull request длы вашей feature branch.

Ветки ошибок

Если есть ошибка в MODX GitHub Issues что вы хотели бы исправить, вот простой рабочий процесс, которому вы можете следовать.

Сначала склонируйте репозиторий MODX Git на github, затем клонируйте свой форк (см. выше).

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

git checkout -b bug-XXXX 2.4.x

Теперь вы готовы внести изменения и исправить неприятную ошибку!

После исправления ошибки вы можете зафиксировать свои изменения и перенести ветку исправления ошибок в форк:

git commit .
git push origin bug-XXXX

Вы готовы выпустить ваш pull request на Github.

Войдите в свою учетную запись Github, найдите форк MODX и нажмите кнопку на которой написано "Pull Request".

Убедитесь, что вы выбрали «базовую ветвь» - вы хотите отправить запрос на получение ветки, из которой вы изначально разветвились (2.4.x в приведенном выше примере).