Git Workflow для поддержания обновленного программного обеспечения с открытым исходным кодом в актуальном состоянии? - PullRequest
Новая
       22

Git Workflow для поддержания обновленного программного обеспечения с открытым исходным кодом в актуальном состоянии?

8 голосов
/ 29 сентября 2010

Наш университет предоставляет услуги веб-хостинга для отделений кампуса на серверах, которыми мы управляем.Установка сторонних программ с открытым исходным кодом требует изменения прав доступа к файлам и кода в программе до ее запуска.(Мы используем suEXEC, если вы знакомы.)

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

Я хочу начать использовать контроль версий (в частности, git) для отслеживания наших пользовательских изменений вместо того, чтобы полагаться на сценарий для внесения изменений, но я не уверен в том, какой рабочий процесс использовать.Я знаком с ветвлением и слиянием, но не знаю, как интегрировать наши старые изменения при выпуске нового выпуска.

Каким должен быть мой рабочий процесс git для интеграции новых изменений из ядра WordPress, но также и для сохранениянаши старые пользовательские изменения?

Ответы [ 2 ]

9 голосов
/ 29 сентября 2010

Я бы посоветовал хранить ваши изменения в ветке и перебирать эту ветку в соответствии с последними из WordPress при каждом обновлении.В грубые сроки ... 

              +-- WordPress 1.0
              v
[master] --*--*
               \
[custom]        *--*--*     <- your customizations

Если вы хотите обновить WordPress, переключитесь на master и сделайте новый коммит с последним souce (или используйте git-svn для синхронизации master): 

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
               \
[custom]        *--*--*     <- your customizations

Теперь вы можете сделать git rebase master custom, чтобы воспроизвести ваши изменения в соответствии с последними, разрешив любые конфликты на этом пути.В таком случае ваша временная шкала будет выглядеть следующим образом: 

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
                     \
[custom]              *--*--*     <- your customizations

Обновление: Чтобы дать немного обоснования ... Мне нравится этот подход для этой проблемы, потому что он обеспечивает четкое различие между кодом изWordPress и ваши настройки.Когда вы получаете новую версию WordPress, вы действительно не заинтересованы в «интеграции».Вы заинтересованы в повторном применении ваших настроек в новой версии WordPress.На мой взгляд, эту перенастройку легче всего выполнить commit by rebase.Любые конфликты означают, что настройка, скорее всего, сломана, поэтому старая фиксация настройки в любом случае является мусором - лучше просто исправить проблему в ее источнике и сохранить обновленную историю в чистоте.

После обновления master и customперебазировав и подтолкнув, соавторы просто перебазировали бы свою незавершенную работу против последней.

Это только мое мнение, как сторонника слияния.Прелесть Git в том, что редко бывает один правильный ответ.Просто продолжайте настройку, пока не найдете то, что работает для вас.

2 голосов
/ 29 сентября 2010

Мой общий подход состоит в том, чтобы иметь две ветви: upstream и master.Создайте свой репозиторий (который запустит вас в ветке master), проверьте последнюю копию используемого вами вышестоящего кода, а затем создайте ветку upsteram с git branch upstream.Кроме того, создайте тег, указывающий, какую исходную версию вы импортировали, например git tag wordpress-1.0.Для этого я обычно использую облегченные теги (без аннотаций, просто указатель на ревизию). 

[wordpress-1.0]               Key: [tag]
v                                  branch
* <- upstream                      * commit
^- master

Теперь, пока вы все еще в ветке master, скопируйте изменения иотметьте их. Теперь у вас есть две ветви: upstream, которая содержит первоисточник вверх по течению, и master, которая содержит ваши изменения, с историей, показывающей, какие изменения вы внесли в upstream. 

[wordpress-1.0]
v
* <- upstream
 \
  +--* <- master

Сделайте все ваши модификации в ветке master.

[wordpress-1.0]
v
* <- upstream
 \
  +--*--*--* <- master

Когда появится новая версия вышестоящего кода, проверьте ветку upstream (git checkout upstream), очистите все, кроме каталога .git, и скопируйте в новую вышестоящую версию.,Используйте git add -A для внесения всех изменений в предыдущую версию, зафиксируйте их и пометьте. 

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--* <- upstream
 \
  +--*--*--* <- master

Теперь, извлеките master и объедините ваши вышестоящие изменения.На этом этапе вы можете выбрать способ слияния, например, взять новую версию апстрима, взять вашу версию или принять объединенные изменения, так же как вы делаете это при обычном слиянии. 

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--*--------+ <- upstream
 \           \
  +--*--*--*--* <- master

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

[wordpress-1.0]
|  [wordpress-1.1]
|  |           [wordpress-2.0]
v  v           v
*--*--------+--*-+ <- upstream
 \           \    \ 
  +--*--*--*--*----*--* <- master

Надеюсь, что этоПомогите, дайте мне знать, если у вас есть еще вопросы.

...