Репозиторий сайта для заказчика: как управлять кодом и релизами

Гит-репозиторий сайта заказчика — это хранилище исходного кода с историей изменений, к которому у вас как у владельца проекта есть доступ. Он даёт три практических результата: видно, что и когда менялось в коде; изменения проходят предсказуемый путь от задачи до релиза; исходники не остаются только на стороне подрядчика. Ниже — как выстроить такую работу, что проверить при приёмке, какие данные подготовить для оценки и где проходят границы этого решения.

Зачем заказчику гит-репозиторий сайта и где границы решения

Репозиторий — инструмент управления изменениями, а не самоцель. Когда код сайта лежит в системе контроля версий, у вас появляется возможность посмотреть, какие правки вносились, кто их делал и в рамках какой задачи. Без хранилища правки вносятся «на живом» сайте: ошибка сразу влияет на работу, а причину изменений ищут по косвенным признакам.

Сравните два состояния проекта. В первом код существует в единственном экземпляре на сервере, правки вносятся напрямую, а история нигде не сохраняется. Во втором есть хранилище, отдельная копия для разработки и понятный порядок выпуска. Разница видна при инциденте: без истории причину ищут перебором, с историей — смотрят последние изменения.

Границы решения важно обозначить сразу, чтобы не ждать от репозитория лишнего.

• Репозиторий хранит код и его историю. Он не заменяет резервные копии базы данных, пользовательских файлов и настроек окружения — это отдельные контуры.
• Репозиторий сам по себе не ускоряет сайт и не повышает защищённость. Он лишь делает изменения наблюдаемыми и обратимыми.
• Репозиторий не отменяет тестирование. Наличие истории не значит, что правки проверены.
• Репозиторий не решает вопрос владения автоматически: важно, в чьём аккаунте он размещён и у кого есть права.

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

Что такое карта управления кодом и зачем она нужна

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

В карту имеет смысл включить:

• где размещён основной репозиторий и в чьём аккаунте он находится;
• какие есть окружения (боевой сайт, сайт разработки, промежуточный стенд) и как они связаны;
• какие ветки используются и что означает каждая;
• что не попадает в репозиторий и почему;
• кто отвечает за выпуск изменений на боевой сайт;
• как оформляется задача и как она связывается с конкретным изменением в коде;
• где хранятся резервные копии и как выполняется возврат к предыдущему состоянию;
• как осуществляется деплой (выпуск) изменений.

Карта — живой документ. Её обновляют, когда меняется схема окружений или ответственные. Без карты знания остаются у отдельных людей, что рискованно при смене исполнителя. Новый специалист тратит время не на работу, а на восстановление картины: где боевая версия, где тестовая, какие правки уже выпущены, а какие ждут проверки.

Практический смысл карты в том, что она переводит устные договорённости в проверяемые факты. Вместо вопроса «а как у вас всё устроено?» вы открываете документ и сверяете реальность с описанной схемой. Расхождения — повод разобраться до того, как они превратятся в проблему.

Владение исходниками и история изменений

Ключевой вопрос для заказчика — не «есть ли репозиторий», а «у кого он находится». Репозиторий, размещённый в личном аккаунте подрядчика, формально существует, но не даёт вам контроля: при прекращении сотрудничества доступ может быть закрыт, а история — недоступна. Поэтому разумно, чтобы основное хранилище принадлежало вам или вашей организации, а исполнители получали доступ к нему как участники.

История изменений — вторая ценность репозитория. Каждое зафиксированное изменение сопровождается пояснением, что и зачем сделано. Это позволяет:

• понять, когда появилась та или иная правка;
• сопоставить изменение с задачей и её автором;
• вернуться к предыдущему состоянию, если новая версия вызвала проблему;
• оценить объём работ по факту, а не по отчёту.

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

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

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

Связь задачи изменения и релиза

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

Разберём звенья этой цепочки.

Постановка задачи

Задача описывает, что нужно изменить и зачем. Хорошая постановка содержит ожидаемый результат и способ проверки. Без этого невозможно понять, соответствует ли внесённое изменение исходной потребности. Если задача сформулирована как «поправить шапку», а по факту меняется логика вывода меню, при приёмке возникнет спор, который решается только возвратом к исходной формулировке.

Работа в отдельной копии

Правки делаются не на боевом сайте, а на копии для разработки. Именно так устроена типовая схема: разработка ведётся на отдельном сайте, а боевой остаётся нетронутым до момента выпуска. Это ключевое отличие управляемой работы от правок «на живом».

Фиксация изменения

Когда правка готова, она фиксируется в истории с понятным пояснением. Это точка, к которой можно вернуться. Чем аккуратнее оформлены пояснения, тем проще потом разбираться. Пояснение вроде «правка формы заказа по задаче №…» полезнее, чем набор символов (хеш коммита), по которому через месяц ничего не восстановить.

Проверка перед выпуском

Изменение проверяют на тестовом окружении: открывают затронутые страницы, проходят ключевые сценарии, убеждаются, что ничего не сломалось. Только после этого готовится выпуск. Проверка — это не формальность, а способ поймать проблему до того, как её увидят посетители.

Выпуск на боевой сайт

Готовое изменение переносится на боевой сайт. Перед этим делается резервная копия, а план возврата известен заранее. Если что-то пошло не так, есть куда откатиться. Такой порядок даёт заказчику предсказуемость: каждое изменение имеет источник, проверку и точку возврата.

Учебный пример: репозиторий для интернет-магазина

Учебный пример. Данные условные и приведены только для иллюстрации.

Представим компанию, которая управляет интернет-магазином на 1С-Битрикс. Сайт развивается: периодически добавляются новые блоки на главной, меняются формы заказа, дорабатывается шаблон карточки товара. Раньше правки вносились прямо на боевом сайте, и после каждой доработки приходилось проверять вручную, не сломалось ли что-то рядом.

Входные условия:

• один боевой сайт и одна копия для разработки;
• несколько подрядчиков, которые время от времени вносят правки;
• нет единого места, где видно историю изменений;
• резервные копии делаются, но восстановление занимает время.

Что решили сделать:

1. Разместили основной репозиторий в аккаунте компании-заказчика. 2. Настроили исключения: в хранилище попадает только уникальный код проекта, а ядро, каталог загрузок и файлы с параметрами подключения остаются вне него. 3. Зафиксировали в карте управления кодом, какие есть окружения и кто отвечает за выпуск. 4. Договорились, что каждая задача оформляется отдельно, а правки вносятся на копии для разработки. 5. Перед выпуском на боевой сайт делается резервная копия и проверяется затронутый сценарий.

Наблюдаемый результат:

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

Проверка результата в этом примере: заказчик открывает историю и находит изменения по конкретной задаче; убеждается, что в хранилище нет файлов с доступами; проверяет, что после выпуска боевой сайт работает в прежнем режиме, а предыдущее состояние доступно для возврата. Если хотя бы один пункт не подтверждается, работу нельзя считать завершённой.

Как проверить результат и принять работу

Приёмка работы по организации репозитория — это не про визуальные настройки, а про проверяемые факты. Ниже — что имеет смысл проверить.

• Доступ. У вас есть доступ к основному хранилищу, и он не зависит от одного человека.
• Состав. В хранилище лежит уникальный код проекта, а не копия ядра и загруженных файлов.
• Секреты. Файлы с параметрами подключения и другими чувствительными данными не попали в историю.
• История. Изменения сопровождаются понятными пояснениями, по ним можно восстановить ход работ.
• Окружения. Есть отдельная копия для разработки, и правки не вносятся напрямую на боевой сайт.
• Выпуск. Порядок выпуска изменений описан, включает резервную копию и план возврата.
• Ответственный. Понятно, кто отвечает за выпуск и к кому обращаться при инциденте.

Если хотя бы один пункт не выполняется, это повод задать вопрос до подписания акта приёмки, а не после. Проверку удобно проводить вместе с исполнителем: так расхождения выявляются сразу, а не превращаются в переписку.

Таблица принятия решения

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

Типичные ошибки и ограничения

Ошибки, которые встречаются чаще всего.

• Репозиторий есть, но он в личном аккаунте исполнителя. Формально код хранится, фактически вы им не управляете.
• В хранилище попадают файлы с доступами. Это создаёт риск утечки, а чистить историю сложнее, чем не допускать попадания.
• Правки вносятся напрямую на боевой сайт. Репозиторий при этом существует отдельно и не отражает реальное состояние.
• Нет отдельного окружения для разработки. Любая проверка идёт на работающем сайте.
• Пояснения к изменениям бессодержательны. История есть, но восстановить по ней ход работ нельзя.
• Карта управления кодом не ведётся. При смене исполнителя знания теряются.

Ограничения, о которых стоит помнить.

• Репозиторий не хранит базу данных и пользовательские файлы. Для них нужны отдельные резервные копии.
• Организация работы с кодом не заменяет тестирование и не гарантирует отсутствие ошибок.
• Юридические вопросы владения кодом и передачи прав решаются в договоре и требуют сверки с профильным специалистом, а не только технической настройки.
• Если проект долго вёлся без контроля версий, первичное внесение кода в хранилище — отдельная задача со своими рисками.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ по организации репозитория, исполнителю нужны вводные. Чем точнее они собраны, тем реалистичнее оценка.

• Список сайтов и окружений: боевой, тестовый, локальный.
• Платформа и её версия, а также используемые модули и доработки.
• Есть ли уже система контроля версий и в каком состоянии.
• Кто сейчас имеет доступ к серверам и к коду.
• Как вносятся правки сегодня: напрямую или через отдельное окружение.
• Как делаются резервные копии и как выполняется восстановление.
• Кто будет отвечать за выпуск изменений на вашей стороне.
• Требования к хранению чувствительных данных и разграничению доступа.

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

Как выбрать исполнителя для этой задачи

Организация репозитория — задача на стыке администрирования и разработки. Её может закрыть штатный специалист, подрядчик или команда, работающая в модели разработчики в аренду. Если вы выбираете между форматами сотрудничества, полезно заранее понять, как распределяется ответственность за выпуск изменений и кто отвечает за доступы.

Когда проект развивается и требует регулярных доработок, разумно опираться на понятный процесс, а не на разовые договорённости. Как выстроить такую работу, разбирается материал Битрикс-разработчик в аренду — как организовать работу. А если вы ещё определяетесь с форматом — штат, фриланс или команда — пригодится разбор Как нанять программиста Битрикс — штат, фриланс или команда. Вопрос распределения зон ответственности между заказчиком и исполнителем подробно раскрыт в статье Аутстаффинг или аутсорсинг разработки — как распределить ответственность.

Чек-лист приёмки

• Основное хранилище кода находится в аккаунте заказчика или его организации.
• У вас есть рабочий доступ к хранилищу, не зависящий от одного человека.
• В хранилище попадает уникальный код проекта, а не копия ядра и загруженных файлов.
• Файлы с параметрами подключения и другими чувствительными данными исключены из истории.
• Есть отдельное окружение для разработки, правки не вносятся напрямую на боевой сайт.
• Изменения сопровождаются понятными пояснениями, по истории можно восстановить ход работ.
• Порядок выпуска изменений описан и включает резервную копию и план возврата.
• Назначен ответственный за выпуск изменений и порядок действий при инциденте.
• Карта управления кодом оформлена и актуальна.
• Резервные копии базы данных и пользовательских файлов ведутся отдельно от репозитория.

Что дальше

Начните с карты управления кодом: зафиксируйте, где лежит код, какие есть окружения и кто отвечает за выпуск. Затем проверьте состав хранилища и доступы. Если репозитория ещё нет, первым шагом станет его создание в вашем аккаунте и перенос уникального кода, а не всей файловой структуры. Дальше — настройка процесса, чтобы каждая задача проходила через отдельное окружение и проверку перед выпуском.