Сайт, реклама и уверенный рассказ показывают ровно одно: человек умеет себя подать. Чтобы понять, давно ли разработчик работает и сам ли делает то, что показывает, нужен длинный цифровой след, который трудно подделать: история аккаунта, содержимое репозиториев, обсуждения, релизы и продукты, которые запускаются сегодня.
Я проверила этим методом собственный профиль на GitHub и нашла в нём шесть дыр. В конце статьи показываю каждую и говорю, что с ней сделала, чтобы вы могли повторить проверку на мне теми же командами.
Что GitHub показывает и чего он не показывает
Календарь вкладов на странице профиля считает далеко не только написанный код. В зелёные квадраты попадают создание репозитория, часть коммитов, заведённые задачи, запросы на слияние, ревью и обсуждения, причём каждое действие учитывается по своим правилам. Плотный календарь поэтому говорит об активности, но не о её содержании.
По умолчанию график показывает только публичную работу. Владелец аккаунта может включить обезличенное число вкладов из закрытых репозиториев, и тогда посторонний увидит ритм по дням, оставаясь без доступа к самому коду. Пустой календарь у коммерческого разработчика поэтому объясним: рабочий код почти всегда закрыт.
Есть и вторая причина пустоты, чисто техническая. Коммит засчитывается аккаунту только тогда, когда почта в заголовке коммита привязана к этому аккаунту, и обычно он должен попасть в основную ветку. Настройка машины с чужой почтой отправляет работу в никуда молча, без единого предупреждения. Разбор причин лежит в документации GitHub.
Главное ограничение метода стоит знать до того, как вы начнёте делать выводы. Git позволяет задать имя, почту и даты автора переменными окружения, поэтому правдоподобная история рисуется за вечер. Зелёный календарь без доступных проектов, обсуждений и релизов остаётся слабым доказательством.
Команды, которыми я проверяю профиль
Первый запрос отвечает на вопрос о возрасте аккаунта и о том, сколько у человека публичных проектов. Поле created_at говорит только о дате регистрации, поэтому дальше его придётся сопоставлять с первыми содержательными коммитами и релизами.
gh api users/LOGIN --jq '{login, created_at, public_repos, followers, company, blog}'
# ритм по годам, вместе с закрытой работой, если владелец её показывает
gh api graphql -f query='query{user(login:"LOGIN"){
contributionsCollection(from:"2026-01-01T00:00:00Z",to:"2026-12-31T23:59:59Z"){
restrictedContributionsCount
contributionCalendar{totalContributions}}}}'
Дальше репозиторий нужно склонировать и посмотреть на него изнутри. Три команды ниже показывают, кто писал код, как работа распределена по времени и совпадают ли даты автора с датами коммитера. Расхождение дат само по себе обманом не является, потому что поддерживающий проект человек применяет чужие правки под своим именем.
git shortlog -sne --all
git log --all --format='%h | author:%aI | committer:%cI | %aN | %s' | head -40
git log --since='2 years ago' --numstat --format='%H' | awk 'NF==3 {a+=$1; d+=$2} END {print a, d}'
На самой странице проекта стоит открыть раздел Insights. Вкладка Contributors показывает, кто вносил коммиты и в каком объёме, Code frequency даёт добавления и удаления по неделям, Pulse собирает активность за выбранный период. Описание вкладки с участниками лежит в справке GitHub.
Девять сигналов, которые стоит проверить дважды
- Аккаунт заведён давно, но вся содержательная работа началась прямо перед запуском рекламы.
- Календарь плотный, при этом доступных коммитов, запросов на слияние и обсуждений нет, а объяснения закрытой работой не дают.
- Десятки репозиториев созданы за несколько дней, у них одинаковые описания и одинаковая структура.
- Большинство проектов оказывается копиями чужих репозиториев или учебными примерами с единственным коммитом.
- Проект объявлен многолетним, а история загружена одним импортом, и ни релизов, ни внешних упоминаний у него нет.
- Человек называет себя автором командной работы, но вкладка Contributors и режим blame показывают минимальный вклад.
- На сайте перечислены крупные клиенты, при этом проверяемых продуктов, публикаций и отзывов с независимых доменов нет.
- Разработчик не может воспроизвести запуск своего проекта и найти в нём место, где сделана заявленная функция.
- В коде лежат ключи и пароли, отключённые тесты и пустая обработка ошибок, а зависимости живут без закреплённых версий.
Ни один пункт по отдельности приговором не является. Настораживать должно сочетание нескольких несостыковок сразу, особенно когда на уточняющие вопросы приходят маркетинговые формулировки без файлов, коммитов и примеров сбоев.
Что уликой не считается
- Мало публичных коммитов: коммерческая работа обычно закрыта, часть истории может лежать в другой системе.
- Длинные паузы: опытный инженер месяцами занимается архитектурой, ревью и разбором инцидентов.
- Мало звёзд и подписчиков: это мера известности, и к качеству заказной разработки она отношения почти не имеет.
- Один большой первый коммит: так выглядит законный перенос проекта из другой системы контроля версий.
- Единственный живой репозиторий: продукт, который поддерживают три года, весит больше сотни брошенных демо.
Теперь проверьте меня
Мой профиль лежит по адресу github.com/unnamed00bas, и сегодня утром он проверку проходил плохо. Разбираю его честно, по тем же признакам.
Аккаунт заведён в 2019 году, с 2020 по 2024 в календаре пусто, за 2026 год стоит 5152 вклада. Объяснение простое: 17 лет в ИТ и 14 лет в аудите ИТ означают работу с документами и системами заказчика, и код в те годы был закрытым. Показывать в профиле стало нечего, потому что и не показывали.
Шесть дыр, найденных за один заход, и что с каждой сделано.
Первая: показ вкладов из закрытых репозиториев был выключен, и календарь показывал 108 вкладов за год при пяти с лишним тысячах настоящих. Настройка включается одной галочкой в профиле и открывает только ритм по дням, оставляя код закрытым.
Вторая: часть коммитов уходила с почтой user@example.com, чужой заглушкой из настройки машины. Таких коммитов 398 в одном проекте, и они уже не станут моими: историю я не переписываю, потому что переписанная история проверяется за минуту и стоит доверия целиком. Настройки на обеих рабочих машинах приведены к почте, привязанной к аккаунту.
Третья: из четырнадцати публичных репозиториев описание было у одного. Теперь у каждого живого проекта написано, что он делает и на чём собран.
Четвёртая: три репозитория были пустыми, внутри лежал единственный заголовок в README, а ещё один оказался копией чужого проекта без единой моей правки. Все четыре удалены, потому что брошенная заготовка создаёт шум и мешает увидеть работу.
Пятая, самая показательная: в описании демо-проекта стояло "16+ years", а на сайте и в соседнем разделе того же файла стоит 17 лет. Расхождение внутри одного документа проверяющий находит первым, и оно обесценивает всё остальное. Привела к тому, что написано на сайте.
Шестая: связь сайта и профиля работала в одну сторону. Профиль вёл на promaren.ru, а сайт на профиль не ссылался нигде, и человеку, решившему проверить работу своими глазами, идти было некуда. Ссылка на профиль теперь стоит в подвале сайта.
Что можно проверить прямо сейчас, без моего участия: возраст аккаунта, ритм вкладов по годам, описания проектов, живой стенд демо, историю коммитов по неделям и то, что сайт и профиль ссылаются друг на друга. Если найдёте расхождение, напишите мне, это будет полезный разбор.
Так же я работаю и с чужими системами: вывод делается по следам, которые можно открыть и пересчитать. Если нужен подрядчик, которого можно проверить до подписания договора, посмотрите список продуктов и напишите. Разборы вроде этого выходят в моём канале, t.me/promaren.
Частые вопросы о проверке по GitHub
Что делать, если у разработчика вообще нет публичного профиля?
Это обычная ситуация для человека, который годами работал в найме под соглашением о неразглашении. Попросите другое проверяемое доказательство: работающий продукт с датами публикации, пакет в реестре, документацию, отзыв заказчика с независимого домена. Отсутствие профиля перестаёт быть вопросом, когда есть что открыть вместо него.
Можно ли подделать календарь вкладов?
Да, и это делается за вечер: даты автора и коммитера задаются переменными окружения, а готовые инструменты рисуют правдоподобную историю автоматически. Поэтому календарь смотрят вместе с содержимым проектов, обсуждениями, релизами и внешними упоминаниями того же человека.
Сколько времени занимает такая проверка?
Первый слой занимает минут двадцать: профиль, описания, пара запросов к открытому интерфейсу GitHub. Разбор одного проекта на экране добавляет сорок пять минут. Оплачиваемое задание растягивается на день или два, и оно же отвечает на главный вопрос о том, справится ли человек с вашей задачей.
Стоит ли просить доступ к закрытому коду?
Просить доступ к чужому коммерческому коду не нужно, и спокойный отказ здесь считается хорошим знаком. Достаточно разбора на экране владельца: он открывает проект сам, показывает решения и отвечает на вопросы, ничего не выгружая наружу.
Что просить у подрядчика до договора
- Ссылку на профиль, названную им самим, и совпадение имени, сайта и почты между профилем и сайтом.
- Один проект на экране: точки входа, хранение данных, внешние интеграции, границы модулей.
- Один содержательный запрос на слияние: задача, альтернативы, замечания ревью, тесты, последствия.
- Реальный сбой: как воспроизвели, как нашли причину, что сделали, чтобы он не повторился.
- Сборку и запуск по инструкции из README в чистом окружении, без подсказок автора.
- Короткое оплачиваемое задание того же типа, что и будущая работа, с заранее оговорённым объёмом.
- Ответ на вопрос, что он сегодня переписал бы в этом проекте и почему.
Проверка занимает вечер и экономит месяцы. Дешевле потратить его до подписания, чем выяснять потом, что показанное на сайте собрано чужими руками.
