Хранить или нет папку /bitrix и /upload в git?

Question

[Алексей]

Собираюсь перейти работать с проектами на битрикс через контроль версий, и возник вопрос по тому, хранить ли данные файлов /bitrix и /upload в репозитории?

Мое мнение, что им в репозитории не место, но терзают сомнения как быть с автономностью, ибо без бекапа сайта на той же тестовой площадке сайт не развернуть.

Comments

[Alams Stoyne]

Хранить смысла нет, для теста проще выкачать /bitrix и /upload ибо Битрикс делает кеш и ресайз одним словом задолбаешся каждый раз заливать изменения с сервера в git

[Lynn «Кофеман»]

Бэкап и исходный код это разные вещи. В гите обычно (в 99% случаев) хранят исходный код

Answer 1

[Сергей]

В гите достаточно хранить только папку local и всю работу вести в ней

Answer 2

[serginhold]

/upload точно нет, он у всех разный будет на тестовых копиях, и может разрастись до нескольких гб.

/bitrix можно, но не весь, а сделать кучу исключений для вложенных папок: кеш, обновления, бекапы (может ещё какие забыл).

Comments

[Виктор Таран]

а зачем? все что вам нужно должно быть в папке /local

[serginhold]

Виктор Таран, а ядро из битрикс бекапов чтоли разворачивать? как бы если и не класть под основной гит, то класть под отдельный гит;
стянул и забыл, чем кнопки нажимать..

[Сергей]

Ядро сколько весит, пол гига? Там миллион файлов, нафиг оно под гитом?
Ядро проще rsync'ом забирать. Обновили на проде, рстнкнули и готово.

[serginhold]

Сергей, как будешь следить за изменениями в ядре? Ясен пень что там руками править ничего не нужно, но вдруг если кто-то что-то все таки поправил и сломал

[Сергей]

serginhold, никак. Нафиг оно надо? За 10 работы ещё ни разу не столкнулся с тем, чтобы мне пригодилось ядро в гите.
А обновления как потом как накатывать, если проду нельзя пушить?
Ну и с таким подходом нужно вообще весь сервер в гит покложить.

[serginhold]

Сергей,

А обновления как потом как накатывать, если проду нельзя пушить?

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

Что будешь делать если при обновлении всё ляжет?) из бекапа через restore.php странностями заниматься? когда можно сделать git reset.
просто я имею ввиду не говносайтики с базой в 200мб, а крупные проекты с базой под 100 гб.. (тем кому давно нужно линять с битрикса)
там захочешь не обновишься одной кнопкой, особенно если пару лет как обновлений не устанавливали

вообще, мое мнение, ядро надо делать под-модулем git, и не мешается в основном репозитории, и под контролем;
после обновлений коммитим в под-модуле все что изменилось, а в основном репозитории коммитим коммит под-модуля

Answer 3

[Вячеслав Шевченко]

Хранить эти папки не нужно. Ниже приведу свой .gitignore

.DS_Store
Thumbs.db
/.idea/
/bitrix/*
/upload/*
/local/templates/tmpl/*.css
/sitemap*
node_modules/*
package-lock.json
.gitignore
/img/*

немного поясню:
/local/templates/tmpl/*.css
Я не храню css файлы т.к. использую scss и собираю его.
/sitemap*
Ну сайт мап просто не нужен.

node_modules/*
package-lock.json

Node используется для сборки css и js и в git не нужен
/img/*
Я убираю img из гита так как есть папка img_src в которой хранятся оригиналы картинок и сжимаются в img/

Comments

[serginhold]

Я не храню css файлы т.к. использую scss и собираю его

и не лень каждый раз на проде сборщик запускать? если можно результат закомитить и при выкладке будет просто git pull

package-lock.json
Node используется для сборки css и js и в git не нужен

серьезно? не комитить lock файл? и при каждом запуске сборщика ожидать неизвестное поведение, т.к. какой-то пакет мог обновится и сломать совместимость?
composer.lock может тоже не хранишь, и вместо install используешь update ?))

[Сергей]

А публичные файлы, которые контент редакторы будут менять?

[Вячеслав Шевченко]

и не лень каждый раз на проде сборщик запускать? если можно результат закомитить и при выкладке будет просто git pull

На этом проекте гит только, чтобы понимать что делалось в проекте. Тут нет деления на ветки в принципе. И деплой идет не через гит, просто по фтп код автоматом деплоится сразу на продакшн, а то, что собирается также автоматом сборщиком деплоится.
Моя схема очень проблемная - вкурсе. В идеале отдельная ветка для каждой фичи и т.д. Но ооочень часто, почти всегда правки делаются чуть ли не под диктовку, правки отступов, замена иконок, картинок делается на связи с заказчиком сразу, нет предварительной подготовки эскизов и т.е. заказчик должен видеть все сразу,а для этого по любому приходится деплоить все сразу, да в идеале не на прод а на тест и заказчик там бы и смотрел, но также бывает такое что фича реализуется не на лету а на протяжении недели и по готовности ее надо протестировать и залить на прод и при этом также могут быть задачи которые надо делать сразу же в отдельной ветке и также чтобы заказчик все видел. Короче тут мне пришлось бы вести отдельный хост на каждую фичу-ветку так чтобы заказчик все тоже видел, а сайт весит около 100гб сейчас и получается что мне пришлось бы иметь минимум 200гб под текущую версию сайта + версию для разработки + еще хотя бы 300гб под резервные копии, а это пока дорого для заказчика.

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

[Вячеслав Шевченко]

Сергей, к счастью часто таких файлов не много и они должны быть в гите. Если мы говорим о более или менее общепринятой схеме работы с гитом то при pull на прод мы получим конфликт, с которым разберемся.
Тут еще надо понимать, что может изменить контент-менеджер. Просто текст или настройки компонента. Если просто текст, то можно создать папку include, в которой хранить файлы с обычным текстом и подключать его в нужных местах, который и будет менять КМ и завести эту папку в .gitignore. А вот если КМ меняет настройки компонента, то мы должны их видеть в любом случае т.к. это настройки напрямую влияют на результат работы кода.

[serginhold]

Вячеслав Шевченко, судя по описанию, у тебя там гит чисто для себя, ты один разраб, и ide синхронизирована с боем. В общем жесть и ужас. Найди себе нормальную работу) где понимают как нужно разрабатывать и выкладывать задачи. На таких работах и платят больше

[Вячеслав Шевченко]

Да, только для себя. Я один фрилансер. Вообще все эти технологии git, docker, различные фреймворки я учу только для себя. Заказчикам это вообще до лампочки.