✂️ Как полностью стереть файл из истории? (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 | #урок

😎 Ностальгия: воскрешаем ICQ

Open OSCAR Server — сервер для мгновенного обмена сообщениями с открытым исходным кодом, который позволяет работать классическим клиентам AIM и ICQ.

👉 Создан как фан-проект для некоммерческого использования. Доступен для запуска на Windows, Linux и macOS.

Клик

➡️ GitHub Ready | #урок

awesome-3d-printing

Это подборка лучших ресурсов, инструментов и программ для 3D-печати, собранных в одном репозитории.

Репозиторий содержит ссылки на программы для создания, редактирования и подготовки 3D-моделей, а также утилиты для управления принтерами.

Здесь собраны как средства моделирования, так и ПО для слайсинга, мониторинга и анализа данных о печати.

Cсылка на GitHub

➡️ GitHub Ready | #урок