Git для новичков: как не сломать проект при первом commit и push

hannadev

Git - это инструмент, который помогает сохранять версии проекта и работать с командой. Многие новички на первом commit и push случайно ломают репозиторий: стирают файлы, добавляют мусор или путаются в ветках. Эта статья покажет, как сделать первые шаги правильно, шаг за шагом.

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

Готовим проект к первому коммиту

Перед тем как делать commit, нужно понять, что Git видит в твоем проекте. Представь, что репозиторий - это фотоальбом: каждый снимок (commit) фиксирует состояние файлов. Если добавить лишнее, потом сложно будет отчистить.

Сначала инициализируй репозиторий командой git init. Это создаст скрытую папку .git, где хранится вся магия. Проверь статус: git status покажет, какие файлы изменились. Новички часто забывают, что Git игнорирует не добавленные файлы - они как черновики, не попавшие в финальный снимок.

Теперь подумай о файле .gitignore. Это список того, что Git не должен трогать: логи, временные файлы IDE вроде .vscode/, сборки build/ или node_modules/. Без него в коммит улетит куча мусора, и репозиторий раздуется.

Создай .gitignore сразу: добавь строки вроде node_modules/, *.log, dist/.
Проверь git status - убедись, что мусор не отображается.
Важно: если файл уже заиндексирован, удали его из индекса git rm --cached filename.

Ошибка новичков	Почему опасно	Как исправить
`git add .` без .gitignore	Добавляет node_modules (сотни МБ)	Создай .gitignore и `git reset`.
Забыть о временных файлах	История засоряется, push тормозит	Всегда проверяй `git status`.
Игнорировать IDE-файлы	Локальные настройки мешают команде	Добавь .vscode/, .idea/ в .gitignore.

Пишем коммит, который поймут все

Commit - это момент истины: ты фиксируешь изменения навсегда (или почти). Плохое сообщение - как записка без подписи: никто не поймет, что ты сделал. Хорошее - краткое, но информативное, помогает через месяцы вспомнить, зачем менял код.

Стандарт: первая строка до 50 символов, в повелительном наклонении. Add вместо Added, Fix вместо Fixed. Без точки в конце. Если нужно объяснить - после пустой строки добавь детали. Это как Conventional Commits: feat: добавь новую кнопку, fix: поправь баг с формой.

Пример: ты добавил index.html и style.css. Не пиши “update”. Пиши: git commit -m "feat: add initial HTML structure and basic styles". Потом git log --oneline покажет чистую историю.

git add filename - добавь конкретный файл.
git add . - осторожно, только после .gitignore.
git add -A - все изменения, но рискуешь мусором.
Проверь перед commit: git diff --staged.

Тип коммита	Пример	Когда использовать
feat	feat: add login form	Новая функция.
fix	fix: resolve CSS overflow	Исправление бага.
docs	docs: update README	Документация.
refactor	refactor: extract utils	Переструктуризация без фич.

Безопасный push: синхронизируйся и не перезаписывай

Push отправляет твои коммиты на сервер (GitHub, GitLab). Но если там уже есть изменения, возникнет конфликт. Новички давят git push --force и стирают чужой код - проект в беде.

Сначала подтяни свежие изменения: git pull origin main. Лучше с rebase: git pull --rebase origin main. Это накладывает твои коммиты поверх новых, история остается линейной, без merge-коммитов. Потом git push origin main.

Если первая отправка - создай репозиторий на сервере, добавь remote: git remote add origin URL. Push в master или main. Нюанс: если ветка защищена, push отклонится - создай pull request.

git fetch - посмотри изменения без слияния.
git pull --rebase - безопасное обновление.
git push origin branch - укажи ветку.
Никогда не force на main: используй только в своей feature-ветке.

Команда	Что делает	Когда применять
git pull	Fetch + merge	Быстро, но грязная история.
git pull --rebase	Fetch + rebase	Чистая линейная история.
git push --force-with-lease	Force с проверкой	Только если уверен.

Ветки: не ломай main с первого раза

Ветка - как копия проекта для экспериментов. Main - священная, туда только готовый код. Новички коммитят прямо в main и пугают команду.

Создай feature-ветку: git checkout -b feature/new-button. Работай там, коммить, push git push origin feature/new-button. Потом pull request на main. Это изолирует изменения.

Если накосячил: git checkout main, git merge feature/xxx или через PR. Совет: перед push проверяй git log --graph.

git branch - список веток.
git checkout -b name - новая ветка.
git switch main - переключиться.

Частые ловушки с ветками

Ловушка	Симптом	Спасение
Push в main случайно	История замусорена	Создай новую ветку заранее.
Конфликт при merge	Файлы сломаны	`git mergetool` или вручную.
Забыл pull перед push	Rejected	`git pull --rebase`.

Что Git скрывает от глаз новичка

Освоил commit и push - уже круто, проект цел. Но Git полон подводных камней: rebase меняет историю, reset стирает коммиты, stash прячет изменения. Подумай, как интегрировать это в workflow.

Дальше изучи aliases вроде git config --global alias.st status - экономит время. Или cherry-pick для выборочного копирования. Это сделает тебя увереннее в команде.