git рабочий процесс для обновления специально модифицированного программного обеспечения с открытым исходным кодом?

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

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

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

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

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

Мой общий подход состоит в том, чтобы иметь две ветки, 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 

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