Мой первый Pet + GitHub: быстро и только нужное — commit, push, pull, работа только в main

GitHub — это мощный инструмент для контроля версий, но часто разработчики с первых дней усложняют себе жизнь лишними ветками, merge-конфликтами и сложными workflow. В статье разберём, как работать эффективно: только main, минимум команд, максимум результата.

Вы только что написали классный код.
Теперь нужно:
1) git add .
2) git commit -m "fix"
3) git push
4) Вернуться к работе.

Всё. Никаких rebase, squash, cherry-pick — только быстро и по делу.

🧠 Теория: почему main?

Главный принцип:

«Если код готов — он в main. Если не готов — его нет в репозитории.»

Это упрощает:

• Историю коммитов — не нужно разбираться в ветках feature/login-validation-v2-final.
• Деплой — всегда актуальная версия в одной ветке.
• Коллаборацию — меньше конфликтов при слиянии.

Когда это работает?

• На старте pet проекта, где вы один разработчик
• При частых маленьких коммитах
• В целом, не критично, если упадет прод или уже есть CI/CD, тесты перед деплоем.

🔧 Практика: базовые команды

1. Добавляем изменения

git add .  # или конкретные файлы: git add app/models/user.rb

2. Коммитим

git commit -m "Добавил валидацию email в User"

Совет:
Пишите сообщения так, будто объясняете коллеге зачем, а не что изменили.
❌ Плохо: fix bug
✅ Хорошо: Исправил N+1 запрос в списке пользователей

3. Пушим

git push origin main

4. А как же git pull origin main?

Вам не надо обновлять локальную версию, если: вы один разработчик и пушите только с одного компьютера.

Вот улучшенная версия раздела, с более точной терминологией, примерами и чуть более дружелюбной формулировкой:

💡 Антипаттерны

1. «Я потом разберусь с конфликтами»

Проблема: Ты вносишь изменения, а потом делаешь git push --force, потому что «локально всё работает».

# Так делать не надо:
git push --force  # 💥 Перезапишешь историю всем — коллеги будут в восторге

❌ Это затирает чужие коммиты, если кто-то уже запушил в main. Даже если проект только твой, можно случайно потерять историю.

✅ Правильный путь

Если твоя ветка отстаёт от удалённого main, подтяни изменения:

git fetch origin
git merge origin/main
# или, если любишь линейную историю:
git rebase origin/main

Если уже пришлось форсить, используй --force-with-lease — это безопаснее:

git push --force-with-lease

Он не перезапишет чужие коммиты, если они появились после твоего последнего fetch.

📌 Вывод: Не форси main просто так. Даже на pet-проектах — хорошая привычка с самого начала.

2. Мега-коммиты

git commit -m "Всё сразу: и фронт, и бэк, и фиксы"

Проблема:
Такой коммит невозможно откатить частично.

3. Ветки «на всякий случай»

git checkout -b experimental-refactoring-2024

Итог:
Через месяц никто не вспомнит, зачем эта ветка, и можно ли её удалить.

🧪 Обязательно .gitignore: защита от утечек и мусора

.gitignore — это не просто список исключений, а первая линия обороны твоего проекта от:

• утечек конфиденциальной информации (ключи, пароли, токены)
• мусора (tmp/, log/, node_modules/)
• лишних конфликтов в командной работе (автогенерируемые файлы)

📄 Пример .gitignore для pet-проекта:

# Конфигурации и секреты
.env
config/database.yml
config/master.key

# Временные файлы
/tmp
/log
/storage
.byebug_history

# Сборка фронтенда
/node_modules
/public/packs
/public/assets

# Системные файлы
.DS_Store
.idea
.vscode

💡 Если используешь Docker, добавь *.local.yml, docker-compose.override.yml и secrets/.

❗ А если уже добавил что-то чувствительное?

🧷 Сценарий А: сделал commit, но ещё не делал push

1. Убери файл из индекса:

   git rm --cached config/database.yml
   

2. Добавь в .gitignore:

   echo "config/database.yml" >> .gitignore
   

3. Сделай новый коммит:

   git commit -m "remove config from repo"
   

🎉 Готово — файл остался у тебя локально, но больше не трекается.

☠️ Сценарий B: уже сделал push в репозиторий

1. Удали файл и добавь в .gitignore:

   git rm --cached .env
   echo ".env" >> .gitignore
   git commit -m "remove leaked file"
   git push
   

2. Если файл содержит секреты (ключи, пароли):

   • немедленно удали или отозви скомпрометированные ключи
   • пересоздай .env или master.key

3. (по желанию) Перепиши историю и удаление из Git-истории:

   # ⚠ Используй только если понимаешь последствия
   git filter-branch --force --index-filter \
     "git rm --cached --ignore-unmatch .env" \
     --prune-empty --tag-name-filter cat -- --all
   git push --force
   

🛑 GitHub всё равно может кэшировать коммиты — удаление файла из истории не гарантирует безопасность. Лучше отозвать ключи и заменить.

✅ Вывод

• Создай .gitignore перед первым коммитом
• Никогда не храни ключи и пароли в репозитории
• Даже в pet-проектах — привычка игнорировать чувствительные файлы защитит тебя в будущем

🔥 Экстренные случаи

Отмена последнего коммита (ещё не запушили):

git reset --soft HEAD~1

Вернуть удалённый файл:

git checkout -- app/controllers/users_controller.rb

🧾 Вывод

GitHub — это инструмент, а не ритуал.

• Коммитите часто.
• Пушите аккуратно.
• Не создавайте ветки без явной необходимости. На старте это не так важно, чем хороший .gitignore.

Ваш идеальный день:
1) Написал код → 2) Закомитил → 3) Запушил → 4) Пошёл пить кофе. ☕