Как оформить GitHub-профиль для поиска работы
Практика3 минРедакция Innovialabs
Коротко
Заполните шапку профиля, добавьте короткий profile README, закрепите 4–6 лучших репозиториев с понятными описаниями и README, а в коммитах показывайте регулярную и осмысленную работу.
Что смотрят в GitHub-профиле
Рекрутер или техлид обычно тратит на профиль немного времени. За это время он хочет понять:
- кто вы и с каким стеком работаете;
- какие проекты стоит открыть в первую очередь;
- как вы пишете код и оформляете работу;
- насколько регулярно вы что-то делаете.
Задача профиля — быстро ответить на эти вопросы и провести человека к лучшим проектам.
Шаг 1. Базовые данные профиля
В настройках профиля заполните:
- имя — то же, что в резюме;
- фото — нейтральное, на котором видно лицо;
- bio — одна строка: роль и стек, например «Backend-разработчик: Python, Django, PostgreSQL»;
- город или часовой пояс;
- ссылки на сайт-портфолио и LinkedIn;
- email для связи, если готовы его показывать.
Шаг 2. Profile README
GitHub показывает README на странице профиля, если создать публичный репозиторий с именем, совпадающим с вашим логином, и добавить в него файл README.md.
Держите его коротким. Пример структуры:
### Привет, я Азиз — frontend-разработчик
Делаю быстрые и доступные интерфейсы на React и TypeScript.
**Сейчас:** изучаю тестирование интерфейсов и доступность.
**Стек:** React, TypeScript, Next.js, Tailwind CSS, Git
**Проекты:**
- [Название проекта](ссылка) — что делает, в одной фразе
- [Название проекта](ссылка) — что делает, в одной фразе
**Связаться:** email · LinkedIn · Telegram
Чего избегать: десятков бейджей технологий, анимированных счётчиков и виджетов со статистикой, которые занимают экран, но ничего не сообщают о ваших навыках.
Шаг 3. Закреплённые репозитории
На профиле можно закрепить до шести репозиториев — это ваша витрина. Выберите 4–6 лучших проектов, подходящих под желаемую роль. Учебные упражнения и форки без изменений лучше не закреплять.
Каждому закреплённому репозиторию нужны:
- понятное название вместо «test-project-2» или «final-final»;
- описание в поле About — одна фраза о том, что делает проект;
- ссылка на демо в поле Website;
- topics — теги со стеком:
react,typescript,postgresql.
Шаг 4. README каждого проекта
Открыв репозиторий, человек должен за несколько секунд понять, что это и как посмотреть результат:
- Что делает проект и для кого.
- Скриншот, GIF или ссылка на демо.
- Стек.
- Как запустить локально — команды, которые действительно работают.
- Ключевые решения и что было сложно.
Также проверьте, что в репозитории нет .env-файлов, ключей и паролей, а в .gitignore исключены зависимости и сборочные файлы.
Шаг 5. История коммитов
Рекрутеры и инженеры обращают внимание на то, как вы работаете с Git.
| Хороший сигнал | Плохой сигнал |
|---|---|
| Небольшие коммиты с понятными сообщениями | Один коммит со всем проектом |
| Сообщения вида «Add search filter by date» | «fix», «asdf», «update» |
| Работа ветками и pull request’ами | Всё сразу в main без истории |
| Проект развивается во времени | Все коммиты за один вечер |
Пример понятных сообщений:
git commit -m "Add pagination to product list"
git commit -m "Fix crash when cart is empty"
git commit -m "Refactor auth service into separate module"
График активности не обязан быть «зелёным» каждый день — важна осмысленная работа, а не количество. Если вы много работаете в закрытых репозиториях, в настройках профиля можно включить отображение приватной активности: содержимое останется скрытым, но график станет честнее.
Частые ошибки
- Профиль без имени, фото и описания.
- Закреплены форки чужих проектов без собственных изменений.
- Репозитории без README или с README по умолчанию.
- Секретные ключи в истории коммитов. Удаление файла в новом коммите не убирает его из истории — ключ нужно отозвать и выпустить новый.