Контроль версий
При доработке решения рекомендуется использовать систему контроля версий (git) для отслеживания изменений в файлах при обновлении решения, а также при восстановлении собственных доработок.
Рекомендуемый файл .gitignore для backend:
.idea/
.vscode/
slim.phpunit.result.cache
.htaccess
.nuxt/
*.txt
*.zip
*.csv
*.gz
*.tar
/upload/
!/bitrix
/bitrix/*
!/bitrix/components
/bitrix/components/*
!/bitrix/components/astdesign
!/bitrix/components/astdesign/*
!/bitrix/modules
/bitrix/modules/*
!/bitrix/modules/astdesign.marketpro
!/bitrix/modules/astdesign.marketpro/*
!/bitrix/admin
/bitrix/admin/*
!/bitrix/admin/astdesign*
!/bitrix/templates
/bitrix/templates/*
!/bitrix/templates/astdesign_marketpro_mails
composer.lock
/slim/logs/*
*.md
/slim/coverage/
/slim/vendor/
/slim/var/cache/
/slim/tests/
/files/*
!/files/cron
*.stamp
*.data
*.log
/.DS_Store
*.png
*.jpg
/desktop_app/
/auth/
/pub/
/storage.php
/index.php
/node_modules/
/bitrix/modules/astdesign.marketpro/install/wizards/astdesign/marketpro/site/services/iblock/xml
/nuxt.config.js
/package.json
/static/sw.js
/local/dev/onlyfix
.htsecure
/slim/logs/
/slim/var/
/slim/vendor/
/upload
/bitrix
/package-lock.json
*.ico
*.js
/images
/static
.access.php
404.php
*.yml
*.dist
*.xml
*.md
*.lock
*.json
/include/
/mobile/
/biconnector/
*.html
/frontend/
/learning/
/local/logs/
/local/files/
/slim/logs
/slim/tests
/slim/vendor
/slim/var
/install.config
/readme.php
/php/cron
/php/toolsДополните список тем, что не должно попасть в репозиторий ни при каких условиях: файлы с секретами (.env), собранная клиентская часть (/frontend/), *.lock и *.json из корня. Секреты в истории git — отдельная беда: удалить их оттуда сложнее, чем не добавлять.
Что обязательно держать под контролем версий
Доработки решения живут в нескольких местах, и после обновления восстанавливать их придётся по одному. Проще заранее держать в git именно эти файлы:
Файл или папка | Что там | Обновление затирает |
|---|---|---|
| переопределённые методы и модификаторы | нет, сборщик пакета исключает эту папку |
| свои настройки решения | может — файл входит в поставку модуля и однажды уже попадал в пакет обновления |
| переопределённые надписи | нет, файла нет в поставке |
| свои маршруты API | нет, они лежат вне модуля |
Из таблицы следует главное: единственный файл доработок, который стоит проверять после каждого обновления, — custom_params.php. Если он оказался с пустым массивом, значит обновление его перезаписало, и настройки нужно вернуть из репозитория.
Как это помогает при обновлении
Порядок такой: перед обновлением — коммит, после обновления — git status и git diff. Вы сразу видите, какие файлы решение переписало, и можете вернуть свои правки одной командой, а не искать их по памяти.
Заодно git diff показывает, что именно изменилось в самом решении: это самый быстрый способ понять, почему после обновления поведение стало другим.