9 апреля в 12:51
Есть локальная разработка и есть рабочий сервер. Использую git и gitlab. В .gitignore включено всё, что не должно быть на проде. В частности
/web/sites/*/settings.local.php
/web/sites/*/files/
/web/sites/*/services.yml
/web/sites/*/files/
/web/sites/*/services.yml
Теперь понадобилось сделать полную копию именно локальной разработки на другом компе, чтобы все эти файлы там были. Иногда бывает нужно поработать с разных компов. Хотелось бы чтобы в репозитории gitlab всё это хранилось, но оно туда не попадает из-за .gitignore. Как в таких случаях вообще действуют? Может всё просто.... но я в git новичок.
Комментарии
Клонируете git, и копируете именно то что указали выше вручную. Вам же на один комп?
на еще один. То есть, локальная разработка может вестись с двух компов. И на каждом надо иметь возможность получить актуальные данные из репозитория. И запушить после работы туда актуальные данные. И при этом нужна возможность пулить данные на рабочий сервер с любого компа (без файлов, которые исключительно для local).
а заливать вручную надо в ту же ветку?
Те файлы и папки что в .gitignore - с ними можете делать что угодно.
Ну для этого гит и нужен.
Ну лучше сделать отдельную ветку для разработки, а потом пулить в основную и на рабочий сервер уже из основной.
правильно я понимаю в целом: создаем две ветки - main и, например, dev. В main пушим всё, что не в .gitignore. В dev передаем только то, что нужно для локальной разработки и что изначально в .gitignore.
Потом на другом компе для локальной разработки получаем данные из обеих веток, а для прода только из main?
То, что в gitignore вообще ни в какую ветку не надо пушить. Если часто надо деплоить на локальных окружениях и это прямо вызывает у вас затруднения, скопируйте ваш локальный settings.php например в default.local.settings.php и вот его уже добавьте в репозиторий. А при первичном локальном деплое просто нужно скопировать этот файл под именем settings.php
дело не только в settings.php. Мне нужны и файлы, которые я использую для тестирования созданных материалов, и дамп бд... который я делаю в конце рабочего дня. Нужна ПОЛНАЯ копия моей локальной разработки на другом компе. Сегодня я на работе, а завтра из дома... Случается такое иногда. И на этот случай нужно чтобы в репозитории была вся локальная версия. Но в то же время этот же репозиторий нужен для деплоя на рабочий сервер.
Файлам из материалов и дампам базы данных точно не место в репозитории.
почему?
Потому что размер репозитория со временем будет космический из-за того, что все файлы, в том числе удалённые, будут занимать место. Плюс бэкапы базы. Плюс потенциальные конфликты.
Рекомендую потратить время на это видео https://niklan.net/blog/186 (автоматизация есть и в гитхабе теперь, сам автор тоже перешел на него).
Будет бОльше понимания процесса.
Вы в гите храните по сути совсем чуть чуть (конфиги, композерские файлы, кастомные темы/модули, я еще js либы храню там, но если их через композер ставить, то не нужно)
по этому видео у меня процесс и настроен. И давно. Но это видео не решает мою задачу: возможность вести разработку на нескольких компах, то есть хранить локальную версию целиком (со всеми local.settings.php и .gitignore) на нескольких компах.
Не совсем понятно, в чём проблема копировать файлы, которые указаны в .gitignore?
Разработчики сами должны забирать/создавать эти файлы с бекапа или с какого-то определенного сервера (prod, dev и тд).
проблемы в том, чтобы все хранилось в одном месте. В конце дня я делаю пару команд git и хочу чтобы в репозитории сохранилось ВСЁ. Чтобы если вдруг завтра придется работать с другого компа, то мне не нужно было тратить время на восстановление файлов разработки, которые не попали в репо из-за gitignore.
Это конечно не такая уж большая проблема... Просто стало интересно, как в принципе люди поступают в подобных случаях.
И еще повторюсь, я пока новичок в git и вероятно хочу от него того, для чего он не предназначен.
>> время на восстановление файлов разработки
Нет там файлов для разработки, там только локальные настройки и всякие файлы в /files.
1. Простое решение - хранить всё-всё в бекапе и восстанавливать там где нужно;
2. Плохое решение — убрать с .gitignore нужные вам файлы, чтобы отслеживать в git;
3. Обычное решение — вручную.
4. Чуть получше — использовать всякие sync-и для files, если вам это так нужно. Плюс - для локальных настроек хранить всё в одном месте - dot.env. Как всё это настраивать - отдельная сказка.
Файлы "разработки" - это что вы под этим понимаете?
Отделите в голове понятия контента и кода, будет проще.
Что касается кода, хранится в гите, контент - нет.
ЗЫ А вам не проще на сервере развернуть дев, и работать с ним из любого места?
файлы разработки - то что перечислено в изначальном посте + дамп бд + каталог с файлами. Последние две позиции нужны на этапе разработки, когда есть только локальная версия сайта. Потом это всё, понятное дело, будет браться с прода.
Во, а я думал я один такой
не проще. Есть ощутимые сложности получения удаленного доступа к серверам организации.
ну свой сервер стоит 300-500 р в месяц
А вы экспортом и импортом конфигов вообще пользуетесь?
когда ведутся доработки сайта, который уже на проде. Всё, как в статье Никлана
Это работает не только на проде. Можно и нужно точно так же синхронизировать настройки на всех средах. Тогда и бэкап базы таскать не надо туда-сюда.
а как синхронизировать БД?
Когда разработка закончена я заливаю базу на прод. И всё. Если нужно доработать что-то и нужна актуальная база - беру ее с прода. А дальше эскспорт/импорт конфигов.
Если забыть о проде. Вот нет его пока. Есть просто два не связанных между собой компа. На обоих docksal с идентичными настройками. Осталось синхронизировать собственно проекты рабочие. Как?
Поработал день, покодил, настройки покликал, сделал экспорт конфигов, закоммитил конфиги и код, запушил. На другом компе git pull, затем drush cim. И вот уже все настройки сайта идентичные.
А контент с одной среды на другую таскать особого смысла нет. Иногда даже полезно вручную создать пару нод, чтобы убедиться, что сам процесс создания или редактирования работает правильно.
мда... почему-то думала (мало еще опыта с 10-кой), что через конфиги можно только редактировать БД, а не создавать новые таблицы. Оказывается можно всё. И тогда, действительно, вопрос с дампом отпадает.
Спасибо!
Наводящий вопрос: Чем прод отличается от вашего второго рабочего ПК?
тем же, чем и от первого рабочего ПК. На проде разработка не ведется.
еще подумайте. Я вам не зря про две ветки сказал в начале. Про конфиги Алексей вам выше описал, что собственно было у Никлана в блоге.
конфиги были мною явно недооценены
Спасибо всем за помощь!