GitHub-профиль легко превратить в витрину: анимированный заголовок, счетчики просмотров, десятки бейджей, графики активности, случайные карточки языков. Все это может выглядеть живо, но работодатель или сильный коллега ищет другое: какие задачи вы решали, как оформляете проект, можно ли запустить код, есть ли тесты, понятны ли ограничения и видно ли развитие мысли. Хорошее портфолио не кричит я много коммитил. Оно показывает, что вы умеете доводить небольшие системы до понятного состояния.
Популярные статьи о README на Хабре полезны как каталог приемов, но важная оговорка из другого разбора остается в силе: GitHub не является универсальным измерителем разработчика. У многих сильных инженеров нет публичных коммитов из-за NDA, продуктовой работы или внутренних репозиториев. Поэтому профиль лучше воспринимать как дополнительное доказательство, а не как замену резюме, собеседования и реального опыта.
Какие проекты закреплять
Закрепленные репозитории должны отвечать на вопрос: какую задачу этот человек может решить. Лучше три законченных проекта, чем десять форков без контекста. Один проект может показывать фронтенд и UX, второй — API и базу данных, третий — автоматизацию, CLI или работу с данными. Если вы претендуете на backend, не ставьте на первое место только лендинги. Если на frontend, не прячьте живой demo и скриншоты. Если на junior, покажите аккуратность и обучаемость: это ценнее псевдо-сложности.
| Элемент | Зачем нужен | Хороший признак | Плохой признак |
|---|---|---|---|
| README | Объясняет задачу и запуск | Есть цель, стек, установка, demo, ограничения | Только название и список технологий |
| Структура проекта | Показывает мышление | Папки названы по ответственности | Все лежит в одном файле без причины |
| Тесты или проверки | Доказывают инженерную дисциплину | Есть команда проверки и понятный scope | Тесты заявлены, но не запускаются |
| История коммитов | Показывает процесс | Коммиты отражают этапы работы | fix, final, final2, trash |
| Issues или roadmap | Показывают самооценку | Есть известные ограничения | Проект притворяется идеальным |
README профиля и README проекта
README профиля — это обложка. В ней достаточно кратко сказать, кто вы, с чем работаете, какие проекты стоит посмотреть и как связаться. Анимации и виджеты допустимы, если не мешают. Но главная ценность в README проекта. Он должен объяснить, зачем проект существует, какую проблему решает, как его запустить, какие решения приняты и что не сделано. Если человек не может запустить проект за 5-10 минут по инструкции, README не выполняет свою работу.
Хороший README не обязан быть длинным. Он должен быть честным. Если проект учебный, так и напишите, но добавьте, что именно вы сделали сверх задания. Если demo не работает без внешнего ключа, объясните, как использовать mock. Если база нужна локально, дайте команду миграции. Если проект недоделан, вынесите ограничения. Парадоксально, но честный раздел Ограничения часто повышает доверие: он показывает, что автор понимает границы решения.
# Название проекта
Коротко: какую задачу решает проект и для кого.
## Demo
Ссылка или скриншот, если есть.
## Стек
Основные технологии и почему они выбраны.
## Запуск
1. Установить зависимости
2. Создать .env из .env.example
3. Запустить миграции
4. Выполнить тесты
## Ограничения
Что осознанно не сделано и почему.Коммиты и история работы
История коммитов не обязана быть идеальной, но она не должна выглядеть как свалка. Для портфолио полезно разбивать работу на понятные шаги: scaffold, data model, validation, UI, tests, docs. Это помогает проверяющему увидеть процесс. Не нужно искусственно переписывать всю историю ради красоты, но последние проекты стоит вести аккуратно. Коммит add tests говорит больше, чем очередной update, если в diff действительно видны проверки.
- Переименуйте закрепленные репозитории так, чтобы смысл был понятен без открытия.
- Добавьте topic-теги: react, nextjs, nodejs, cli, postgres, testing, data и другие реальные технологии.
- Уберите из публичного доступа секреты, дампы, .env и случайные ключи.
- Проверьте, что npm test, pnpm test или другая команда из README реально запускается.
- Добавьте скриншоты для визуальных проектов и пример входных данных для CLI/API.
- Не накручивайте счетчики и не выдавайте генератор профиля за инженерную работу.
Как показать опыт без большого open source
Если вся работа закрыта NDA, можно сделать маленькие демонстрационные проекты. Не клон большого сервиса, а узкая задача: валидатор формы с доступностью, API для заметок с миграциями и тестами, парсер CSV с отчетом, мини-дэшборд с фильтрами, CLI для рутинной операции. Важно не количество строк, а завершенность. Проект должен иметь понятный сценарий, документацию, проверки и ограничения. Тогда он говорит о дисциплине больше, чем огромная недоделанная копия маркетплейса.
Можно показывать и текстовые артефакты: технические заметки, архитектурные решения, ADR, схемы данных, инструкции запуска. Для многих ролей это особенно ценно. Разработчик, который умеет объяснять решения, быстрее встраивается в команду. Но тексты должны относиться к проекту, а не быть набором общих фраз о чистом коде.
Чего лучше избегать
Не стоит делать профиль перегруженным. Десятки виджетов, мигающие баннеры, музыка, случайные шутки и огромные списки технологий могут скрыть главное. Не добавляйте технологии, которыми не пользовались. Не оставляйте мертвые demo-ссылки. Не публикуйте чужие учебные решения без собственных изменений. Не пишите в README, что проект production-ready, если там нет обработки ошибок, тестов и документации. Проверяющий быстро видит разрыв между обещанием и кодом.
Итог: GitHub-портфолио работает, когда оно доказывает конкретные навыки. Профиль — короткая навигация, закрепленные проекты — лучшие примеры, README — инструкция и контекст, тесты — дисциплина, история коммитов — процесс. Виджеты можно оставить как оформление, но они не заменяют проект, который запускается, решает задачу и честно описывает свои ограничения.
Комментарии
Загружаем обсуждение.