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

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

Что такое репозиторий простыми словами?

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

Чаще всего за этим стоит Git — программа, которая ведёт историю изменений. Сам Git работает на компьютере разработчика, а чтобы у команды была общая копия, репозиторий размещают на сервисе: GitHub, GitLab или другом. Когда говорят «репозиторий на гитхабе», имеют в виду именно эту общую копию, которую можно открыть в браузере.

Несколько слов, которые встретятся в переписке с разработчиками:

• Коммит — одна сохранённая порция изменений с описанием, например «добавил оплату картой».
• Ветка — параллельная линия работы: новую функцию делают в отдельной ветке, чтобы не сломать рабочую версию, а потом сливают.
• Пул-реквест (в GitLab — merge request) — заявка «посмотрите и примите мои изменения». Здесь же коллеги оставляют замечания.
• README — главный текстовый файл проекта: что это, как запустить, где что лежит.

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

Зачем заказчику доступ к репозиторию?

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

Практически доступ даёт четыре вещи:

1. Видно, что работа идёт. Отчёт можно написать красиво, а история изменений показывает факты: в какие дни менялся код и что именно делали.
2. Проект не привязан к одному человеку. Фрилансер заболел, студия закрылась, сотрудник уволился — новый разработчик начнёт с репозитория, а не с нуля.
3. Можно позвать независимого эксперта. Если сомневаетесь в качестве, дайте доступ стороннему разработчику на пару часов: он посмотрит структуру, тесты, историю и скажет, всё ли в порядке.
4. Понятно, что сдают. При приёмке вы сравниваете не обещания, а конкретное состояние кода на дату акта.

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

На чьём аккаунте должен быть репозиторий?

На аккаунте заказчика: компании или человека, который отвечает за проект. Подрядчик получает к нему доступ как участник. Тогда смена исполнителя — это вопрос «убрать одного участника и добавить другого», а не переговоры о передаче.

Как это устроить на практике:

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

Есть важная деталь про роли, о которой мало кто знает. В репозитории личного аккаунта GitHub у приглашённых участников одна роль, и это право записи: по справке GitHub, дать участнику доступ только на чтение там нельзя. Набор ролей от Read до Admin есть у репозиториев организации. В GitLab для просмотра кода без права что-то менять служит роль Reporter, а роль Guest код закрытого проекта не показывает.

Отсюда два сценария. Если репозиторий ваш, подрядчику нужно право записи — это нормально, ведь он пишет код. Если подрядчик ведёт репозиторий у себя, просите доступ на чтение: в организации GitHub это роль Read, в GitLab — Reporter. «Гостевой» доступ, при котором код не виден, ничего не даёт.

Бывает, что студии удобнее вести код у себя до сдачи, например когда в проекте её внутренние модули. Это допустимо, если в договоре записано, в какой репозиторий и когда код будет передан. Устный ответ «передадим потом» — не договорённость. О том, как вообще распределять учётные записи проекта, есть отдельный разбор — на кого оформлять домен и хостинг.

Что открыть	Что должно быть	Тревожный признак
Дата последнего изменения	Свежие записи в истории, в дни активной работы — почти каждый день	Недели тишины при отчётах «всё идёт по плану»
Описания изменений	Понятные фразы: «форма заявки: проверка телефона»	Сплошные «fix», «update», «123» или одна огромная запись в конце
Файл README	Что это за проект, чем собирается, где лежит инструкция	Файла нет или в нём заготовка по умолчанию
Инструкция по развёртыванию	Шаги, по которым другой разработчик запустит проект на новом сервере	Инструкция «у меня в голове», ссылки на личный сервер подрядчика
Файлы с настройками	Шаблон вида .env.example с названиями параметров без значений	Пароли, токены, ключи платёжного сервиса прямо в файлах
Список участников	Ваш аккаунт с правами владельца, подрядчик — участник	Вас нет в списке или вы только «гость» в чужом проекте

Что можно проверить в репозитории без программиста?

Достаточно пяти проверок по десять минут: дата последних изменений, понятность описаний, файл README, инструкция по развёртыванию и отсутствие паролей в файлах. Плюс список участников — кто имеет доступ к вашему коду.

Как пользоваться таблицей: откройте репозиторий в браузере. На главной странице сервиса видно дату последнего изменения и текст README. История лежит в разделе Commits (в GitLab — «Коммиты»), участники — в настройках доступа.

Несколько пояснений к пунктам, где чаще всего путаются.

Тишина в истории — не всегда плохо. На этапе дизайна или согласования ТЗ код может не меняться неделями, и это нормально. Тревожно, когда идёт разработка, подрядчик пишет «почти готово», а история пуста или все изменения залиты одним махом накануне сдачи. Второй случай означает, что код писали где-то ещё, и вы не видели промежуточного состояния.

Пароли в коде — серьёзная ошибка, даже в закрытом репозитории. Ключ от платёжного сервиса, пароль от базы данных или токен бота не должны лежать в файлах проекта: доступ к коду получат будущие подрядчики и все, кому вы его покажете. Правильная практика — хранить такие значения на сервере в настройках окружения, а в репозитории держать только шаблон с названиями параметров. Как это проверить без навыков: воспользуйтесь поиском по репозиторию и введите слова password, secret, token, api_key. Если рядом с ними видите длинные строки из букв и цифр — задайте вопрос подрядчику. Для публичных репозиториев GitHub сам бесплатно ищет утёкшие ключи (secret scanning), но на закрытые репозитории личных аккаунтов это бесплатно не распространяется — проверять придётся самим.

README и инструкция — тест на «автобус». Задайте себе вопрос: если разработчик завтра пропадёт, сможет ли другой человек по этим файлам запустить проект? Если в инструкции написано «спросить у Саши», ответ — нет.

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

Что должно быть передано вместе с кодом?

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

Чек-лист для акта сдачи:

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

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

Как это устроено у нас. По типовому договору исходный код передаётся вместе с результатом работ и размещается в репозитории заказчика, указанном в приложении к договору, а если репозитория нет — передаётся архивом, в объёме, достаточном для сборки, развёртывания и доработки (п. 5.5). Какие права на этот код получает заказчик, — в статье по ссылке выше и в разделе 5 образца договора. Что именно передаём по каждому тарифу, записано в прайсе.

Что делать, если подрядчик не даёт доступ?

Сначала выясните причину и запишите договорённость: в какой репозиторий и к какой дате будет передан код. Если подрядчик отказывается без объяснений и это не прописано в договоре, считайте это риском и не платите следующий этап, пока вопрос не решён.

Причины бывают разными, и не все плохие:

• Оплата не завершена. Многие исполнители передают код после окончательного расчёта. Это законная позиция, если так записано в договоре. Тогда попросите хотя бы доступ на чтение к рабочему репозиторию, чтобы видеть ход работ.
• В проекте внутренние модули студии. Тогда уточните, передаются ли они вместе с кодом и в каком виде. Если проект без них не собирается, «передача кода» без модулей — не передача.
• Кода просто нет в репозитории. Например, сайт собран в конструкторе или правится прямо на сервере. Это отдельная история: проект сложно передать и сложно проверить.

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

Когда репозиторий заказчику не нужен и какие ошибки встречаются?

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

Когда можно обойтись без своего репозитория:

• Сайт на конструкторе — там нет исходного кода, который можно перенести. Важнее аккаунт конструктора на вашем имени и экспорт данных.
• Готовая коробочная система с настройкой, где подрядчик ничего не программирует, а только настраивает.
• Небольшой одноразовый проект, например промостраница на месяц, где хватит архива при сдаче.

Ошибки, которые встречаются у заказчиков:

1. Репозиторий на личной почте сотрудника. Сотрудник ушёл — доступ ушёл вместе с ним. Заводите на рабочий адрес компании.
2. Отдали подрядчику права владельца. Владелец может удалить репозиторий или передать его другому аккаунту. Подрядчику хватит прав участника.
3. Не сняли доступы после окончания работ. Закончили сотрудничество — уберите бывшего исполнителя из участников и смените пароли, которые он знал.
4. Проверили один раз при сдаче. Репозиторий полезен как раз по ходу работ. Короткий взгляд раз в неделю заметнее, чем разбор в последний день.
5. Путают репозиторий с резервной копией. В репозитории нет базы данных: заказов, клиентов, загруженных файлов. Их резервные копии — отдельная задача, обычно часть поддержки.

Сколько стоит проект, где код сразу ведётся в вашем репозитории?

У нас это не отдельная услуга: по типовому договору исходный код передаётся вместе с результатом работ, отдельно за это не платят. Лендинг — от 24 000 ₽, корпоративный сайт — от 56 000 ₽, интернет-магазин — от 104 000 ₽, веб-приложение — от 160 000 ₽, мобильное приложение — от 200 000 ₽. Точную цену называем после брифа.

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

Короткие ответы на частые вопросы

Что такое репозиторий простыми словами?

Это хранилище кода проекта вместе с полной историей изменений: какие файлы поменялись, когда, кем и зачем. Обычно его ведут в системе Git и размещают на сервисе вроде GitHub или GitLab, чтобы у команды и заказчика была общая копия.

Нужно ли заказчику разбираться в Git, чтобы пользоваться репозиторием?

Нет. Достаточно открыть репозиторий в браузере, посмотреть дату последних изменений, файл README и список участников. Команды Git нужны разработчикам, а не владельцу проекта.

Почему на GitHub нельзя дать подрядчику доступ только на чтение?

В репозитории личного аккаунта GitHub у приглашённых участников одна роль — с правом записи, режима «только чтение» там нет. Отдельные роли, включая Read, есть у репозиториев организации; в GitLab для просмотра кода есть роль Reporter.

Что делать, если код передали архивом, а не репозиторием?

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

Как устроена передача кода в Roboweb.team?

По типовому договору исходный код передаётся вместе с результатом работ и размещается в репозитории заказчика из приложения к договору, а если его нет — архивом, в объёме, достаточном для сборки, развёртывания и доработки (п. 5.5).

Услуги и кейсы по теме: поддержка сайта от 7 900 ₽/мес · заказная разработка · цены и сроки