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

Question

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

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

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

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

Answer 1

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

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

Когда вы хотите обновить WordPress, переключитесь на Master и сделать новый коммит с последним Souce (или использовать Git-Svn, чтобы сохранить мастеру в синхронизации):

              +-- 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. На мой взгляд, что рекустезирование наиболее легко проводится обаяние путем совершения через ребазу. Любые конфликты означают, что настроен, вероятно, сломал, поэтому старая коммитария Commitiation в любом случае является мусором - лучше просто исправить проблему в своем источнике и сохранить обновленную историю чистота.

После master обновляется и custom Переоборудован и подтолкнулся, сотрудники только что будут сокращать свои работы по сравнению с последним.

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

Answer 2

Мой общий подход - иметь две ветви, upstream и master. Отказ Создайте свой репозиторий (который начнет вас в master ветвь), проверьте в последней копии вышеупомянутого кода, который вы используете, а затем создать upsteram ветвь с git branch upstream. Отказ Кроме того, создайте тег, указывающий, какую версию 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 Code, проверьте свой 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 

Надеюсь, это поможет, дайте мне знать, если у вас есть какие-либо дополнительные вопросы.