Разработчик доделал проект, запушил его на GitHub через пару команд в терминале — и через неделю обнаруживает: половина файлов не отображается, история коммитов пуста, а README лежит мёртвым грузом. Он не ошибся в синтаксисе. Он пропустил ключевые шаги, которые превращают случайный набор файлов в настоящий репозиторий. Загрузить проект на GitHub — это не «скопировать → вставить». Это ритуал, в котором каждое движение имеет смысл.
Первое, что ломает новичков: отсутствие .gitignore
До того как выполнить git init, стоит задуматься: какие файлы вообще не должны попасть в репозиторий? node_modules, .env, сборки, временные файлы IDE — всё это раздувает репозиторий, замедляет клонирование и может привести к утечке данных.
Опытный разработчик создаёт файл .gitignore до первого коммита. Он подбирает шаблон под стек: Python, React, Unity — на GitHub есть официальные шаблоны для каждого. Без этого шага даже простой проект может «взорваться» до сотен мегабайт мусора.
Локальный репозиторий — не просто папка с кодом
Чтобы загрузить проект на GitHub, сначала нужно превратить папку в Git-репозиторий. Это делается командой git init. Но инициализация — только начало.
Следующие шаги критичны:
git add .— добавляет файлы в индекс, но только те, что не исключены через.gitignore.git commit -m "Initial commit"— фиксирует состояние. Без коммита репозиторий пуст, даже если файлы добавлены.git remote add origin https://github.com/ваш-аккаунт/название.git— связывает локальный репозиторий с удалённым.
Ошибка здесь — частая причина «пустого» репозитория на GitHub. Пользователь создаёт репозиторий на сайте, копирует URL, но забывает сделать коммит до git push. Git отказывается пушить — ведь нечего отправлять.
HTTPS vs SSH: не техническая мелочь, а вопрос удобства
При первом пуш-е через HTTPS GitHub запросит логин и пароль. Но с августа 2021 года пароли больше не работают — только personal access token (PAT). Многие тратят часы, пытаясь понять, почему «правильный пароль» не подходит.
SSH — альтернатива, которая избавляет от постоянных запросов авторизации. Настройка занимает пять минут: генерация ключа через ssh-keygen, копирование публичного ключа в настройки GitHub. После этого все операции проходят без паролей.
Специалисты рекомендуют SSH для регулярной работы. HTTPS — лишь для разовых действий или на чужих машинах.
Что делать, если репозиторий уже создан на GitHub?
Иногда разработчик сначала создаёт репозиторий на GitHub с README, лицензией или .gitignore. В этом случае локальный и удалённый репозитории расходятся. Простой git push вызовет конфликт.
Решение — сначала получить изменения с удалённого репозитория:
git remote add origin URLgit pull origin main --allow-unrelated-histories- Разрешить конфликты, если они возникли (обычно это README или .gitignore)
git add . && git commit -m "Merge remote"git push origin main
Этот сценарий — ловушка даже для опытных. Без флага --allow-unrelated-histories Git откажет в слиянии, считая истории несвязанными.
Проверка: ваш проект действительно «загружен»?
После пуша стоит убедиться, что всё на месте:
- Файлы отображаются в веб-интерфейсе, а не только в истории коммитов.
- README.md отформатирован и виден под описанием репозитория.
- Ветка по умолчанию совпадает с локальной (часто
main, но иногдаmaster). - Нет «мёртвых» файлов вроде
.DS_StoreилиThumbs.db— они попадают, если не настроен.gitignore.
Если что-то пошло не так, не поздно исправить. Git позволяет переписать историю локально и запушить заново — главное, не терять исходные файлы.