Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Мои любимые команды Git
На протяжении 10+ лет разработки я использую Git ежедневно и выработал свой набор наиболее полезных команд, которые упрощают работу и помогают избежать проблем.
1. git log с форматированием
git log --oneline --graph --all
Эта команда показывает историю коммитов в красивом формате с визуализацией веток. Намного информативнее, чем базовый git log.
2. git status -sb
git status -sb
Сокращённый формат статуса. Показывает текущую ветку, отслеживаемые файлы и какие коммиты впереди/позади от upstream.
3. git diff --cached
git diff --cached
Показывает, что будет закоммичено. Использую перед каждым commit для проверки, что я не добавил лишнее или не забыл что-то.
4. git rebase -i
git rebase -i HEAD~5
Интерактивный rebase для очистки истории — объединение коммитов, переписание сообщений, удаление опечаток в истории перед push в основную ветку.
5. git stash с сообщением
git stash save "feature: новая функциональность"
Очень полезно при переключении между ветками, когда текущая работа не готова к коммиту. Сообщение помогает вспомнить, что было спрятано.
6. git cherry-pick
git cherry-pick abc1234
Для применения отдельного коммита из другой ветки. Очень удобно при работе с горячими патчами или когда нужна конкретная фиксация в другую ветку.
7. git reflog
git reflog
Спасает, когда что-то пошло не так. Показывает полную историю всех действий с refs, помогает восстановить потерянные коммиты.
8. git bisect
git bisect start
git bisect bad HEAD
git bisect good v1.0
Бинарный поиск коммита, где появился баг. Экономит часы при дебаге регрессий в больших проектах.
Почему эти команды важны
Как архитектор и lead разработчик, я убежден, что чистая история коммитов — это не косметика, а технический долг. Она помогает в code review, более быстром понимании изменений и упрощает отката при проблемах. Git — это не только контроль версий, но и инструмент документирования эволюции проекта.
Обычно я комбинирую эти команды: сначала работаю в отдельной ветке, потом перед merge-запросом очищаю историю через rebase -i, проверяю дифф и только тогда создаю PR.