🌍 Глобальный .gitignore: как не тащить мусор в каждый проект?

Каждый раз при создании нового репозитория мы добавляем в .gitignore одни и те же вещи: логи системы, кэш редактора (вроде .vscode или .idea) или скрытые файлы macOS (.DS_Store). Вместо того чтобы копировать их из проекта в проект, можно настроить один общий список для всего компьютера.

Задача:
— Автоматически игнорировать системный мусор во всех репозиториях.
— Сделать локальные файлы .gitignore чище, оставив там только специфичные для проекта вещи (например, node_modules или dist).

Решение:

Нужно создать один глобальный файл и сказать Git использовать его как эталон.

# 1. Создаем файл для глобального игнора (например, в домашней папке)
touch ~/.gitignore_global

# 2. Добавляем в него стандартный мусор (открой файл и вставь):
# .DS_Store
# .vscode/
# .idea/
# *.log
# thumbs.db

# 3. Регистрируем этот файл в глобальном конфиге Git
git config --global core.excludesfile ~/.gitignore_global

Почему это удобно?
— Чистые коммиты: ты никогда случайно не закинешь свои настройки VS Code в общий репозиторий.
— Экономия времени: создаешь папку, делаешь git init — и базовый игнор уже работает.
— Уважение к коллегам: пользователям Windows не мешают твои файлы из macOS, и наоборот.

Совет: Если ты работаешь на разных ОС, удобно держать такой файл в облаке или синхронизировать его через свой репозиторий с конфигами (dotfiles). А если не знаешь, что именно добавить в список, загляни на gitignore.io — там можно сгенерировать идеальный конфиг под твой стек.

🔥 — если уже настроил глобальный игнор
🤝 — если каждый раз гуглишь «что добавить в gitignore»

➡️ GitHub Ready | #урок

💨 Как «выселить» файл из Git, если он уже там? (Git rm --cached)

Бывает досадно: ты добавил файл в репозиторий, закоммитил его, а потом понял, что это был конфиг с паролями или огромный бинарник, которому там не место. Ты добавляешь его в .gitignore, но... ничего не происходит. Git продолжает следить за файлом, потому что он уже попал в индекс.

Задача:
— Удалить файл из репозитория, но оставить его на компьютере.
— Сделать так, чтобы Git перестал отслеживать изменения в файле.

Решение:

Используем команду rm с флагом --cached. Это «мягкое» удаление: файл исчезнет из следующего коммита и из истории (в будущем), но физически останется в папке.

# 1. Удаляем конкретный файл из индекса
git rm --cached config.json

# 2. Если нужно удалить целую папку (например, случайно добавленные логи)
git rm -r --cached logs/

# 3. Теперь фиксируем изменения
git commit -m "Удалил конфиги из отслеживания"

# 4. Не забудь добавить этот файл/папку в .gitignore, 
# чтобы они снова случайно не попали в индекс!

Почему это важно?
— Безопасность: ты убираешь чувствительные данные из публичного доступа.
— Вес репозитория: удаление лишних тяжелых файлов ускоряет git clone для твоих коллег.
— Чистота: в git status больше не висят файлы, которые не должны быть частью проекта.

Важно: Помни, что этот метод убирает файл из *текущего* состояния и будущих коммитов. В старых коммитах (в истории) файл всё равно останется. Если ты случайно закоммитил пароль от базы данных, его нужно либо менять, либо использовать специальные инструменты для полной очистки истории (например, BFG Repo-Cleaner).

🔥 — если хоть раз забывал скрыть .env
🤝 — если всегда проверяешь git add . перед коммитом

➡️ GitHub Ready | #урок

✂️ Как полностью стереть файл из истории? (BFG Repo-Cleaner)

Мы уже знаем, как перестать отслеживать файл, но что делать, если ты случайно закоммитил пароли, API-ключи или тяжеленное видео на 2 Гб? Даже если ты удалишь их в новом коммите, они навсегда останутся в истории папки .git, раздувая её размер и создавая дыру в безопасности.

Задача:
— Полностью вырезать файл или папку изо всех коммитов, которые когда-либо были сделаны.
— Уменьшить размер репозитория, удалив старые тяжелые вложения.

Решение:

Стандартная команда git filter-branch очень медленная и сложная. Профи используют BFG Repo-Cleaner — это быстрая и простая альтернатива.

# 1. Сначала скачай bfg.jar (через brew или с официального сайта)

# 2. Удалить файл с конкретным именем из всей истории
java -jar bfg.jar --delete-files secret_key.txt

# 3. Удалить все папки с определенным именем (например, старые кэши)
java -jar bfg.jar --delete-folders .trash_data

# 4. После работы BFG нужно запустить очистку мусора самого Git
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Почему это необходимо?
— Безопасность: если ключ попал в историю, его может достать любой, кто склонирует проект.
— Производительность: репозиторий, который весил 500 Мб из-за одной случайной картинки, снова станет легким и быстрым.
— Гигиена: в истории остаются только важные изменения кода, а не случайные ошибки.

Важно: Эта операция полностью переписывает историю. После неё тебе придется сделать git push --force. Обязательно предупреди коллег, чтобы они переклонировали репозиторий, иначе их локальные версии «сойдут с ума» при попытке слияния.

🔥 — если чистил историю после случайного пуша
🤝 — если просто меняешь пароли, если они утекли

➡️ GitHub Ready | #урок

📦 Как временно спрятать код, не создавая коммит? (Git Stash)

Бывает так: ты в самом разгаре работы над сложной фичей, код наполовину переписан, ничего не компилится, и тут прилетает срочный баг-репорт. Нужно бросить всё и переключиться на другую ветку, но Git не дает это сделать, пока в текущей есть незавершенные изменения.

Задача:
— Быстро очистить рабочую область, чтобы переключиться на другую ветку.
— Сохранить текущий прогресс в надежном месте, чтобы вернуться к нему позже.

Решение:

Используем «карман» или «заначку» — команду stash. Она берет все твои незавершенные правки и временно убирает их в специальное хранилище.

# 1. Спрятать все текущие изменения (кроме новых файлов)
git stash

# 2. Спрятать всё, включая новые (untracked) файлы
git stash -u

# 3. Дать "заначке" имя, чтобы не запутаться в них через неделю
git stash save "Работа над корзиной: почти готово"

# 4. Посмотреть список всех своих заначек
git stash list

# 5. Вернуть изменения обратно и удалить их из хранилища
git stash pop

# 6. Вернуть изменения, но оставить их в списке stash
git stash apply

Почему это маст-хэв?
— Чистота истории: тебе не нужно плодить коммиты с названиями «wip» или «temp», которые потом придется склеивать.
— Скорость: переключение между задачами занимает секунды.
— Безопасность: ты не потеряешь свои мысли и наработки при резкой смене контекста.

Совет: Если ты сделал stash pop и получил конфликты — не паникуй. Git вернет код в файлы, но пометит места конфликтов, как при обычном мерже. А если ты хочешь применить «заначку» к совершенно другой ветке — это тоже сработает!

🔥 — если stash — твоя любимая команда
🤝 — если коммитишь всё подряд с сообщением "."

➡️ GitHub Ready | #урок

🎯 Как вытащить из Stash только один файл?

Иногда в «заначке» (stash) лежит целая куча изменений: правки по стилям, новый метод в контроллере и фикс конфига. Тебе нужно вернуть только тот самый конфиг, а остальное оставить «до лучших времен». Стандартный git stash pop вывалит на тебя всё сразу, создавая хаос.

Задача:
— Выборочно достать один или несколько файлов из сохраненного стека.
— Не засорять рабочую область лишним кодом из незавершенной задачи.

Решение:

Используем команду checkout (или restore), указывая путь к файлу и индекс заначки. По умолчанию последняя заначка — это stash@{0}.

# 1. Сначала посмотри список, чтобы найти нужный индекс
git stash list

# 2. Достаем конкретный файл из последней заначки
git checkout stash@{0} -- path/to/file.js

# 3. Если пользуешься современным Git (2.23+), лучше через restore:
git restore --source=stash@{0} path/to/file.js

# 4. Теперь файл у тебя в рабочей директории, а в stash 
# по-прежнему лежит полная копия всех изменений.

Почему это удобно?
— Точечный контроль: ты берешь только то, что нужно здесь и сейчас.
— Безопасность: основная «заначка» остается целой. Если ты что-то испортишь в процессе, всегда можно откатиться и попробовать снова.
— Чистый перенос: так удобно перекидывать мелкие правки между ветками, не делая лишних коммитов.

Совет: Если ты не помнишь, в какой именно заначке лежит нужный файл, используй git stash show -p stash@{1} — это покажет полный дифф (изменения кода) для конкретного сохранения.

🔥 — если любишь хирургическую точность в Git
🤝 — если всегда достаешь всё разом и сидишь в конфликтах

➡️ GitHub Ready | #урок

🌿 Как превратить заначку в отдельную ветку? (Git Stash Branch)

Иногда «заначка» перерастает формат временного решения. Ты спрятал туда пару строк, а потом дописал ещё десяток, и теперь этот код слишком велик и важен, чтобы просто «вываливать» его поверх текущей ветки (особенно если там уже появились конфликты).

Задача:
— Безопасно перенести код из stash в новую чистую ветку.
— Избежать конфликтов, которые возникли бы при обычном pop.

Решение:

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

# Создать новую ветку и перенести туда изменения из последней заначки
git stash branch имя_новой_ветки stash@{0}

# Если заначка всего одна, можно просто:
git stash branch feature-new-logic

Почему это круто?
— Никаких конфликтов: так как ветка создается именно от того состояния кода, в котором вы «сташили» изменения, они применятся идеально.
— Порядок в голове: вы не смешиваете две разные задачи в одной ветке.
— Автоматизация: после успешного создания ветки и применения кода, Git сам удалит эту заначку из списка list.

Когда это использовать?
Лучше всего это работает, когда вы начали делать фичу не в той ветке, вовремя спохватились, сделали stash, а теперь хотите продолжить работу уже в правильном, изолированном месте.

🔥 — если любишь идеальный порядок в ветках
🤝 — если просто копипастишь код в блокнот перед переключением

➡️ GitHub Ready | #урок

🍒 Как перенести один коммит из другой ветки? (Git Cherry-pick)

Иногда тебе не нужна вся ветка коллеги с её десятками коммитов. Тебе нужен только один конкретный фикс или классная функция, которую он уже реализовал. Чтобы не копировать код вручную, в Git есть инструмент для «точечного» копирования.

Задача:
— Скопировать конкретное изменение из любой ветки в текущую.
— Исправить баг в production, взяв готовое решение из develop, не вливая туда всё остальное.

Решение:

Используем команду cherry-pick. Тебе нужно только знать хэш коммита (его можно найти через git log).

# 1. Переходим в ветку, куда хотим добавить изменение
git checkout main

# 2. "Забираем" нужный коммит по его хэшу
git cherry-pick 7b2f3a1

# 3. Если возникли конфликты — правим их и продолжаем:
git add .
git cherry-pick --continue

Почему это удобно?
— Точность: ты берешь только то, что нужно, не прихватывая лишний «мусор» или недоделанные фичи из соседних веток.
— Мобильность: можно переносить исправления между версиями проекта (например, из ветки v2.0 в v1.0).
— Сохранение метаданных: Git сохраняет оригинальное сообщение коммита и автора, что упрощает навигацию в будущем.

Совет: Если тебе нужно забрать сразу несколько коммитов, идущих подряд, можно указать диапазон: git cherry-pick A..B (где А — более старый коммит, а B — более новый).

🔥 — если постоянно «воруешь» фиксы у коллег через cherry-pick
🤝 — если просто ждешь полного мержа веток

➡️ GitHub Ready | #урок

↩️ Как безопасно отменить коммит в общей ветке? (Git Revert)

Когда ошибка уже улетела на сервер (push), использовать reset или amend опасно — это перепишет историю и сломает работу коллегам. Для таких случаев есть «вежливый» способ отката — создание коммита, который делает всё ровно наоборот.

Задача:
— Отменить изменения, которые уже видят другие разработчики.
— Сохранить прозрачную историю: все должны видеть, что баг был и его откатили.

Решение:

Команда revert не удаляет старый коммит, а создает новый «анти-коммит». Если в оригинале вы добавили строку, revert её удалит. Если удалили файл — вернет.

# 1. Отменить самый последний коммит
git revert HEAD

# 2. Отменить конкретный коммит из прошлого по его хэшу
git revert 7b2f3a1

# 3. Отменить сразу несколько коммитов (диапазоном)
git revert A..B

Почему это лучше, чем Reset?
— Безопасность для команды: история только растет вперед, никто не получит ошибку "diverged branches".
— Документация: в логе остается четкий след: «Был коммит X, но мы его отменили коммитом Y из-за проблем».
— Гибкость: можно отменить коммит, который был сделан неделю назад, не затрагивая всё, что было написано после него.

Важно: Если при реверте возникают конфликты, это значит, что более свежий код затронул те же строки, что и отменяемый коммит. В этом случае нужно поправить файлы вручную, сделать git add и git revert --continue.

🔥 — если за чистоту истории в общем репозитории
🤝 — если просто фиксишь баги новыми коммитами поверх старых

➡️ 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 | #урок

🕵️ Как вычислить коммит, который всё сломал? (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 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 | #урок

🔍 Как искать по коду быстрее, чем в 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 | #урок

🏗 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 | #урок

🏷 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 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 | #урок

⌨️ 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 | #урок

🌲 Git Worktree: как работать в двух ветках одновременно?

Представь ситуацию: ты пишешь огромную фичу в ветке feature, у тебя открыты десятки файлов, проект запущен в режиме разработки. Вдруг прилетает критический баг в main, который нужно поправить прямо сейчас. Обычно ты делаешь stash, переключаешься на main, правишь баг, пушишь, возвращаешься в feature и делаешь stash pop. Это долго и сбивает фокус.

Задача:
— Работать над main и feature одновременно.
— Иметь две разные папки на компьютере для одного и того же репозитория.

Решение:

Команда git worktree позволяет «развернуть» любую ветку в отдельную соседнюю папку. Ты просто открываешь её во втором окне IDE.

# 1. Создаем отдельную папку для ветки hotfix (Git сам создаст папку и переключит ветку)
git worktree add ../my-project-hotfix main

# 2. Теперь у тебя на компьютере два независимых рабочих пространства:
# - ~/projects/my-project (твоя текущая фича)
# - ~/projects/my-project-hotfix (чистый main для правок багов)

# 3. Когда баг исправлен и запушен, удаляем рабочее дерево
git worktree remove ../my-project-hotfix

Почему это киллер-фича?
— Никаких переключений: тебе не нужно останавливать сервер, пересобирать зависимости (`npm install`) или прятать код в stash.
— Параллельные тесты: ты можешь запустить тесты в одной папке и продолжать писать код в другой.
— Чистота: файлы не перемешиваются, ты не рискуешь случайно закоммитить код фичи в ветку багфикса.

Совет: Чтобы посмотреть список всех активных рабочих деревьев, используй команду git worktree list. Это поможет не забыть удалить старые папки, когда они станут не нужны.

🔥 — если worktree звучит как спасение для больших проектов
🤝 — если по старинке клонируешь репозиторий второй раз в новую папку

➡️ GitHub Ready | #урок

🔗 Git Submodules: как встроить один репозиторий в другой?

Представь, что у тебя есть три разных проекта, и в каждом из них используется одна и та же библиотека UI-компонентов или модуль авторизации. Копировать код вручную — плохая идея (придется обновлять его в трех местах). Для таких случаев в Git есть механизм подмодулей (Submodules).

Задача:
— Использовать чужой или свой сторонний репозиторий внутри текущего проекта.
— Сохранить возможность обновлять этот внешний код независимо от основного проекта.

Решение:

Мы не просто скачиваем файлы, а сохраняем ссылку на конкретный коммит внешнего репозитория.

# 1. Добавить внешний репозиторий как подмодуль (в папку libs/my-shared-library)
git submodule add https://github.com/user/lib.git libs/my-shared-library

# 2. Когда твои коллеги склонируют проект, им нужно будет инициализировать подмодули:
git submodule update --init --recursive

# 3. Чтобы обновить подмодуль до самой свежей версии из его ветки:
git submodule update --remote libs/my-shared-library

Почему это удобно?
— Единый источник правды: ты правишь библиотеку в одном месте, а обновляется она везде.
— Разделение прав: бэкендеры могут работать в своем репозитории, фронтендеры — в своем, но у них может быть общая папка с типами или конфигами.
— Версионирование: основной проект не сломается, если в библиотеке выйдет баг. Он обновится только тогда, когда ты сам этого захочешь (сдвинешь указатель коммита).

Совет: Будь аккуратен при удалении подмодулей. Это не просто rm -rf, тебе придется удалить упоминания о нем из файлов .gitmodules и .git/config. Если проект разрастается, многие команды со временем переходят на монорепозитории (Monorepos) с использованием инструментов вроде Turborepo или Nx.

🔥 — если делишь код на независимые модули
🤝 — если просто копипастишь папки из проекта в проект


➡️ GitHub Ready | #урок

Ailia-models

Этот репозиторий содержит коллекцию предварительно обученных моделей машинного обучения, совместимых с платформой AILIA SDK. В нем представлены модели для различных задач, включая компьютерное зрение, обработку естественного языка и другие области искусственного интеллекта.

https://github.com/axinc-ai/ailia-models

➡️ GitHub Ready | #урок