У меня есть Git-репозиторий, в котором весь мой код находится в основной ветке, и ранее я просто игнорировал все файлы Drupal, так что я держал строгое разделение между кодом, который я написал (или изменил или мог изменить), и кодом это может быть сгенерировано с помощью Drush или чего-то еще.
Это казалось хорошей стратегией, пока мне не пришлось обновить Drupal. Я понял, что хочу откатиться, если дела пойдут плохо, и какой инструмент лучше использовать, чем Git, для этого. Я подумал про себя, что это будет идеальная ситуация для функциональной ветки, поэтому я создал drupal-7.14ветку, которая сама .gitignoreпо себе игнорирует весь мой код и файлы настроек и обращает внимание только на те файлы, которые являются частью установки Drupal, и я бы этого не сделал. не трогай Я сделал обновление вручную (загрузка, распаковка, распаковка, копирование), перебирая пограничные случаи, такие как robots.txt и .htaccess, и переписывая .gitignore Drupal своим собственным. Я исправил некоторые настройки, которые работали с 7.14, но не с 7.15, чтобы восстановиться после ошибки 500, и тогда все казалось идеальным. Я переименовал филиал в drupal-7.15и собирался идти счастливо.
Пока я не осознал, что сделал непреднамеренно: файлы, которые ранее не отслеживались моей основной веткой, но оставались в рабочем каталоге, теперь удалялись из рабочего каталога, когда я извлекал мастер, так как они больше не были неотслеживаемыми файлами! D'о!
Если я объединю drupal-7.15ветку с мастером, я потеряю разделение кода.
Вероятно, есть какой-то способ преобразовать ветку в подмодуль. Предполагая, что это возможно, это может быть лучшей стратегией. До того, как я это сделал, я знал, что подмодули были «правильным» решением, но, поскольку я не осознавал побочный эффект использования веток для ранее неотслеживаемых файлов, я решил срезать углы и пойти по этому пути. (Кроме того, все подходы, которые я видел к использованию подмодулей с Drupal, предполагают, что вы начинаете новый проект, и Drupal будет основной веткой. Мне нежелательно делать чужой код главной веткой, и у меня уже было репозиторий с мастер-веткой. Это выглядело так, как будто было бы слишком сложно просто выполнить обновление.)
Может быть какое-то другое решение, о котором я не думал.
Как я могу лучше всего оправиться от этого с наименьшим количеством возможных недостатков?
ОБНОВЛЕНИЕ : Это находится в разработке (на виртуальной машине Linux на моем ноутбуке), и еще не запущено в производство. К тому времени, когда мы перейдем к производству, я планирую все обернуть в функциональные модули, но это еще не сделано.
ОБНОВЛЕНИЕ 2 : Подмодули могут не работать. Согласно Pro Git , «Подмодули позволяют вам хранить Git-репозиторий как подкаталог другого Git-репозитория». Drupal не дает такого хорошего разделения. Вместо того, чтобы весь код Drupal находился в подкаталоге, отношения более или менее инвертированы, но чистого разделения по-прежнему нет, поскольку вы, возможно, редактируете свои .htaccess и robots.txt, поэтому ваш код и репозиторий Drupal смешаны вместе. Я ищу решение этой проблемы .
источник
Ответы:
Из приведенного выше обсуждения видно, что ваш вопрос не в исправлении вашего репозитория git, а в том, как поддерживать сайт Drupal в git и как это работает с обновлениями ядра.
Я думаю, что стандартная практика на самом деле хранит все файлы в вашем хранилище, включая ядро Drupal. Отделение кода Drupal от пользовательского кода кажется хорошей идеей, но я не думаю, что это необходимо, и я не вижу, какие преимущества это дает вам. Также кажется, что вы никогда не захотите исправлять ядро (или делать это как часть своего развертывания), что, хотя и не является наилучшей практикой, определенно является тем, что вы захотите сделать, если что-то сломается в производстве. Сохранение ваших коммитов красивыми и сфокусированными также помогает добиться такого разделения.
Решение, которое я использовал, заключается в том, чтобы хранить весь код в одном и том же хранилище, размещать как можно больше в компонентах или других видах экспорта / кода / конфигурации и поддерживать список исправлений, которые необходимо применить к внешним -box ядро и вклад.
Когда вы обновите ядро, запустите его в своей среде разработки:
drush sql-dump). Либо сделайте коммит с дампом, либо сохраните его где-нибудь в безопасности.drush up drupal)drush updbна производство.git reset --hard HEAD~2следует это сделать), либо отмените две фиксации, если вы хотите сохранить историю. Замените свою базу данных дампом.Дамп базы данных необходим, потому что иначе вы не сможете отменить изменения, внесенные в базу данных обновлениями. Вы также можете выполнить обновление в ветке, и в этом случае возврат означает только проверку мастера. Это немного нежелательно, если вы работаете на одном сайте разработчика, потому что вы не можете по-настоящему переключиться обратно на мастер и продолжать работать там параллельно из-за базы данных.
Использование этого более простого рабочего процесса на стороне git позволит вам использовать всю мощь git, когда вам это нужно, без усложнения подмодулей и т. Д. Если это не кажется адекватным, не могли бы вы объяснить, почему вам нужно дальнейшее разделение кода?
источник
Из моих комментариев выше, этот вопрос у вас есть о поддержке файлов сайта Drupal с помощью git и о том, как это работает с обновлениями ядра. Вы ничего не упомянули о резервном копировании и обновлении базы данных. Я постараюсь не копировать ничего из ответа Горона.
Я создал сообщение в блоге об этой проблеме. Обновление ядра Drupal на вашем сайте с помощью Git.
Альтернативные Методы
Вы не заявили об этом, но если вы заинтересованы в отслеживании изменений между версиями Drupal, я бы сделал это, используя теги вместо веток . Как только вы закончите с вашим коммитом обновления до master , пометьте свой код как 7.x.
источник
Я запускаю установку с двумя ветвями, как OP: одна ветвь только с моим пользовательским кодом, а другая ветвь с моими пользовательскими и основными файлами. Я столкнулся с той же ситуацией: игнорируемые файлы ядра удаляются при переключении между ветками.
В итоге у меня было два идентичных каталога git: один - для работы с моим пользовательским кодом, файлы ядра присутствуют, но игнорируются, и я никогда не переключусь на «полную» ветвь в этом каталоге - один для выполнения слияний, чтобы я мог выполнить переключение и объединение ветвей только внутри этого каталога.
Причина, по которой я выбрал эту настройку с двумя ветвями, заключается в том, что я хочу легко отслеживать все локальные коммиты в файлах ядра, поэтому проще проверять и повторно применять моды ядра при обновлении файлов ядра.
источник