Вы узнаете, как подготовить файлы, написать хорошее сообщение коммита и безопасно отправить изменения на сервер. Простые примеры и 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.

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

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.

Безопасный 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-ветке.

Ветки: не ломай 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 - переключиться.

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

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

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

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