GitHub Ready | Git

🏷 Conventional Commits: как писать сообщения, которые поймут все? Когда ты заглядываешь в git log через месяц, сообщения типа «fix», «updated» или «добавил кнопку» не говорят ни о чем. Чтобы история проекта была читаемой, разработчики придумали стандарт Conventional Commits. Это делает твой репозиторий профессиональным и позволяет автоматически генерировать список изменений (Changelog). Задача: — Сделать историю коммитов понятной с первого взгляда. — Разделить исправления багов, новые фичи и изменения в документации. Решение: Структура сообщения выглядит так: тип(область): описание. Основные типы: — feat: новая функциональность (например, feat(auth): add google login). — fix: исправление ошибки (fix(api): resolve timeout on large requests). — docs: изменения в документации (docs(readme): add installation steps). — style: правки оформления (пробелы, форматирование), которые не влияют на логику. — refactor: правка кода, которая не добавляет фичу и не фиксит баг. — chore: обновление зависимостей или настроек сборки. — test: добавление или исправление тестов. Почему это круто? — Скорость: ты сразу видишь, что именно произошло в коде, не открывая сам коммит. — Автоматизация: инструменты вроде *Semantic Release* могут сами поднимать версию проекта (v1.0.1 -> v1.1.0), опираясь на твои feat и fix. — Порядок: это дисциплинирует не пихать в один коммит и новую фичу, и правку старого бага. Совет: Если изменение «ломает» обратную совместимость (Breaking Change), в конце типа ставят восклицательный знак, например: feat(api)!: change response format. 🔥 — если уже пишешь коммиты по стандарту 🤝 — если «fix» — твое второе имя ➡️ GitHub Ready | #урок

⌨️ Git Aliases: как перестать печатать длинные команды? Если ты ловишь себя на том, что в сотый раз за день вводишь git status или git commit -m "...", пора признать: лень — двигатель прогресса. В Git можно создавать свои короткие псевдонимы (алиасы) для любых команд, превращая сложные конструкции в пару букв. Задача: — Сократить время на ввод стандартных команд. — Создать свои «супер-команды», которые объединяют несколько действий в одно. Решение: Алиасы настраиваются через глобальный конфиг. После этого они будут работать во всех твоих проектах.

    
        # 1. Самые популярные сокращения
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm "commit -m"

# 2. Продвинутый лог (красивое дерево истории одной командой 'git lg')
git config --global alias.lg "log --graph --oneline --all --decorate"

# 3. Как это использовать в терминале:
git st          # вместо git status
git co main     # вместо git checkout main
git cm "feat: add login"
{}
    

Почему это маст-хэв? — Скорость: git lg за секунду показывает всю структуру веток, которую в обычном логе не разобрать. — Меньше опечаток: чем короче команда, тем меньше шанс ошибиться в буквах. — Кастомизация: ты можешь настроить Git под свой стиль работы, как удобное кресло. Совет: Если ты хочешь посмотреть все свои текущие алиасы, введи git config --get-regexp alias. А если работаешь в Zsh или Oh My Zsh, там уже встроены сотни готовых алиасов (например, gst для статуса или gcap для commit & push). 🔥 — если твой .gitconfig уже забит алиасами 🤝 — если до сих пор пишешь команды целиком для тренировки памяти ➡️ GitHub Ready | #урок

Dashdot Это инструмент с открытым исходным кодом, позволяющий отслеживать состояние вашего сервера через удобный веб-интерфейс. Программа отображает данные о процессоре, оперативной памяти, хранилище, а также сетевой активности в реальном времени. Dashdot легко настраивается, поддерживает работу через Docker и предлагает различные виджеты для индивидуальной настройки панели мониторинга. Это идеальное решение для разработчиков и администраторов, которые хотят всегда быть в курсе состояния своих серверов. https://github.com/MauriceNino/dashdot ➡️ GitHub Ready | #урок

🕵️ Кто это сделал? Находим автора каждой строки (Git Blame) Бывает, открываешь файл и видишь странный кусок кода, который ломает тебе всю логику. Хочется спросить автора: «Зачем здесь это условие?». Чтобы не гадать и не пролистывать всю историю коммитов, в Git есть инструмент «расследования». Задача: — Узнать, кто последним редактировал конкретную строку. — Найти коммит, в котором появилось это изменение. — Понять контекст: когда и в рамках какой задачи был написан этот код. Решение: Используем команду blame. Она выводит содержимое файла, а слева от каждой строки подписывает хэш коммита, автора и дату.

    
        # Посмотреть авторов всех строк в файле
git blame path/to/file.js

# Если файл огромный, смотрим только нужный диапазон (например, с 10 по 20 строку)
git blame -L 10,20 path/to/file.js

# Показать e-mail автора вместо имени (удобно, если в команде два Ивана)
git blame -e path/to/file.js
{}
    

Почему это полезно? — Экономия времени: не нужно вручную искать, когда изменилась функция. — Коммуникация: ты точно знаешь, к кому подойти за пояснениями по коду. — Ретроспектива: часто видишь, что «костыль» был поставлен три года назад для бага, которого уже не существует. Совет: В современных IDE (VS Code, WebStorm) есть плагины вроде GitLens. Они показывают информацию из blame прямо в редакторе серым текстом в конце текущей строки. Это позволяет проводить «расследование», даже не открывая терминал. 🔥 — если постоянно проверяешь, кто накодил этот шедевр 🤝 — если и так помнишь весь свой код (и чужой тоже) ➡️ GitHub Ready | #урок

🤡 ТЕБЯ УНИЗИЛИ, А ТЫ СТЕРПЕЛ? Братан, это ужасно плохо, тебе нужно вы%бать обидчика, он это заслужил, держи мануал: 1. Заходишь в бота (кидаешь uнфy, которая есть) 2. Получаешь uнфy об обидчике (собираем все вместе) 3. Пишем мамахе обидчику привет со скринами сынули ☠️ Если чо, ссылка на бота с мануала тут - t.me/appropriate1_bot?start=refSkalaTg

🪝 Git Hooks: как заставить проект проверять самого себя? Представь: ты в спешке сделал коммит, забыл прогнать тесты или оставил в коде console.log. Всё это улетает в репозиторий, ломает сборку у коллег или просто засоряет проект. Git Hooks (хуки) — это скрипты, которые автоматически запускаются при определенных действиях (коммит, пуш, мерж) и могут отменить операцию, если что-то не так. Задача: — Автоматически проверять код на ошибки (ESLint, Prettier) перед каждым коммитом. — Запускать тесты только для измененных файлов. — Запрещать пушить в ветку main напрямую. Решение: Хуки живут в папке .git/hooks, но их неудобно синхронизировать с командой. Поэтому в JS-мире чаще всего используют инструмент Husky.

    
        # 1. Устанавливаем Husky
npx husky-init && npm install

# 2. Создаем хук пре-коммита (pre-commit)
# Теперь перед каждым 'git commit' будет запускаться проверка
npx husky add .husky/pre-commit "npm test"

# 3. Для продвинутых: используем lint-staged, 
# чтобы проверять только те файлы, которые ты изменил, а не весь проект.
{}
    

Почему это спасает нервы? — Чистый код: проект всегда отформатирован по единому стандарту, и никто не «забывает» запустить линтер. — Стабильность: если тесты упали, коммит просто не создастся. Тебе придется сначала всё починить. — Экономия времени на ревью: коллегам не нужно указывать тебе на лишние пробелы или пропущенные точки с запятой — хуки всё исправят за тебя. Совет: Если тебе очень нужно сделать коммит прямо сейчас (например, ты сохраняешь черновик и точно знаешь, что тесты упадут), можно обойти хуки флагом --no-verify: git commit -m "wip" --no-verify. Но используй это только в крайних случаях! 🔥 — если в твоих проектах всегда стоят хуки 🤝 — если узнал о них только что, но уже хочешь внедрить ➡️ GitHub Ready | #урок

🏗 Rebase vs Merge: как не превратить историю в «спагетти»? Когда приходит время вливать свою ветку в main, перед тобой встает выбор: нажать кнопку Merge или использовать Rebase. Оба способа объединяют код, но делают это совершенно по-разному. Задача: — Объединить наработки из разных веток. — Решить, важна ли тебе хронология событий или «чистая» прямая линия коммитов. Решение: 1. Git Merge (Консервативный путь) Создает специальный «мерж-коммит», который связывает две ветки.

    
        git checkout main
git merge feature-branch
{}
    

— Плюсы: сохраняется история того, когда ветка была создана и влита. Это безопасно для общих веток. — Минусы: если веток много, история превращается в запутанный клубок линий. 2. Git Rebase (Путь перфекциониста) Берет твои коммиты и «переклеивает» их поверх последних коммитов из main.

    
        git checkout feature-branch
git rebase main
{}
    

— Плюсы: история выглядит как одна прямая линия, её легко читать. — Минусы: переписывается история (хэши коммитов меняются). Никогда не делай ребейз в ветках, с которыми работают другие люди! Почему это важно? — Для работы в команде: обычно договариваются об одном стиле. Например: «все фичи вливаем через rebase, а релизы через merge». — Для поиска багов: по прямой линии (после ребейза) гораздо проще искать ошибки через bisect. — Для эстетики: чистый git log — это просто приятно. Совет: Если ты запутался в процессе ребейза, всегда можно всё отменить командой git rebase --abort. 🔥 — если за идеальную линию в rebase 🤝 — если доверяешь только классическому merge ➡️ GitHub Ready | #урок

🔍 Как искать по коду быстрее, чем в IDE? (Git Grep) Когда проект разрастается до тысяч файлов, обычный поиск в VS Code или WebStorm может начать подтормаживать, индексируя всё подряд. У Git есть встроенный инструмент поиска, который работает напрямую с базой данных репозитория — это невероятно быстро. Задача: — Найти все упоминания функции или переменной во всем проекте. — Найти строку кода не только в текущем состоянии, но и в других ветках или старых коммитах. Решение: Используем команду grep. Она оптимизирована для работы с текстовыми файлами внутри Git.

    
        # Найти строку "authService" во всех файлах проекта
git grep "authService"

# Показать номера строк, где найдено совпадение
git grep -n "api_key"

# Ограничить поиск только определенным типом файлов (например, JS)
git grep "useEffect" -- '*.js'

# Самое крутое: поиск в другой ветке (не переключаясь на неё!)
git grep "new_feature" feature-branch

# Найти, сколько раз встречается слово (подсчет)
git grep -c "TODO"
{}
    

Почему это мощнее обычного поиска? — Скорость: Git ищет по своим индексам, что почти всегда быстрее, чем перебор файлов файловой системой. — Гибкость: ты можешь искать код в истории или в ветках, которых у тебя даже нет «развернутыми» в папке. — Чистота: git grep автоматически игнорирует всё, что прописано в .gitignore (никакого мусора из node_modules или dist в результатах). Совет: Если хочешь увидеть контекст (строки до и после найденной), добавь флаги -B (before) и -A (after). Например, git grep -C 2 "function" покажет саму строку и по 2 строки вокруг неё. 🔥 — если терминал для тебя быстрее любого GUI 🤝 — если по старинке жмешь Ctrl + Shift + F ➡️ GitHub Ready | #урок

🕵️ Как вычислить коммит, который всё сломал? (Git Bisect) Бывает так: вчера проект работал идеально, а сегодня — всё падает. Ты не знаешь, в какой именно момент закралась ошибка, ведь за день было сделано 20 коммитов разными людьми. Перебирать каждый вручную — долго и мучительно. Задача: — Быстро найти тот самый «плохой» коммит среди десятков других. — Автоматизировать поиск бага, даже если ты не знаешь, где именно в коде проблема. Решение: Используем «бинарный поиск» через git bisect. Git делит историю пополам, спрашивает тебя «тут работает?», и так за считанные шаги находит виновника.

    
        # 1. Запускаем процесс
git bisect start

# 2. Помечаем текущее состояние как "плохое" (тут баг есть)
git bisect bad

# 3. Указываем хэш коммита, когда всё точно работало (например, вчерашний)
git bisect good 7b2f3a1

# Git переключит тебя на коммит ровно посередине.
# Проверяешь код (запускаешь тесты или приложение).

# 4. Если баг остался:
git bisect bad
# Если всё работает:
git bisect good

# Повторяй, пока Git не выдаст хэш того самого коммита-преступника.
# 5. Завершаем поиск и возвращаемся в реальность:
git bisect reset
{}
    

Почему это магия? — Скорость: чтобы найти ошибку среди 1000 коммитов, тебе понадобится всего около 10 проверок. — Точность: исключается человеческий фактор «проглядел». — Автоматизация: если у тебя есть готовый тест (скрипт), можно запустить git bisect run ./test.sh, и Git сам найдет баг, пока ты пьешь кофе. Совет: Это лучший способ разобраться в чужом (или своем старом) коде, когда ты точно знаешь, что «раньше было лучше», но не понимаешь, почему всё сломалось сейчас. 🔥 — если bisect — твой главный детектив 🤝 — если ищешь баги глазами до победного ➡️ GitHub Ready | #урок

🧩 Как навести порядок в истории? (Git Squash) Когда ты работаешь над фичей, в истории часто скапливается мусор: «Fix typo», «WIP», «Another fix», «Check CI». Отправлять такой хаос в основную ветку — плохой тон. Перед мержем лучше «склеить» (squash) все мелкие правки в один чистый и понятный коммит. Задача: — Превратить серию мелких коммитов в один логический. — Сделать историю проекта понятной для коллег, которые будут читать её спустя месяц. Решение: Самый мощный способ — интерактивный ребейз (interactive rebase).

    
        # 1. Запускаем ребейз для последних N коммитов (например, 3)
git rebase -i HEAD~3

# 2. В открывшемся редакторе ты увидишь список коммитов:
# pick a1b2c3d Сообщение 1
# pick e4f5g6h Сообщение 2
# pick i7j8k9l Сообщение 3

# 3. Замени слово 'pick' на 'squash' (или просто 's') 
# для тех коммитов, которые хочешь "влить" в предыдущий:
# pick a1b2c3d Сообщение 1
# squash e4f5g6h Сообщение 2
# squash i7j8k9l Сообщение 3

# 4. Сохрани и закрой файл. Git предложит написать новое,
# общее сообщение для объединенного коммита.
{}
    

Почему это важно? — Читаемость: вместо десяти правок в git log видна одна четкая задача: «Реализована авторизация через Google». — Легкий откат: если фича сломала проект, её можно отменить одним git revert, а не выискивать все мелкие кусочки. — Профессионализм: твой Pull Request выглядит аккуратно, что очень радует тимлидов на код-ревью. Важно: Как и любой ребейз, делай это только с локальными коммитами, которые еще не ушли в общий доступ. 🔥 — если всегда причесываешь историю перед пушем 🤝 — если оставляешь всё как есть, «пусть мучаются» ➡️ GitHub Ready | #урок