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

🔍 Как найти коммит, который сломал сборку? (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 | #урок

Bubble Tea — это мощный и элегантный фреймворк для создания терминальных пользовательских интерфейсов (TUI) на языке Go. С его помощью можно легко разрабатывать интерактивные и динамичные консольные приложения.

Основные особенности Bubble Tea:
- Модельная архитектура: реализация на основе архитектуры Model-Update-View (MUV), напоминающей Elm.
- Гибкость: подходит как для простых CLI-приложений, так и для сложных интерфейсов с анимацией.
- Совместимость: легко интегрируется с другими библиотеками и инструментами на Go.
- Поддержка таймеров и анимации: для создания динамичных эффектов.
- Простота тестирования: чистый и читаемый код.

https://github.com/charmbracelet/bubbletea

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

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

🤖 Внушительный набор алгоритмов для робототехники на Python

В репозитории Python-Robotics лежит большой набор различных алгоритмов для робототехники, написанных на языке Python.

👉 Основное внимание уделяется автономной навигации, а цель — помочь новичкам в робототехнике понять основные идеи, лежащие в основе каждого алгоритма.

Клик

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

goose

С AI в разработке на более сложных задачах часто приходится несколько раз гонять диалог туда-сюда: править код, дебажить, деплоить. И на каждом шаге нужно следить за процессом. Когда есть время, норм, а когда завал, это становится довольно геморно.

Недавно наткнулся на Goose, open source AI-проект, который уже набрал 31000+ звезд и может полностью автоматически закрывать сложные инженерные задачи.

Ключевая фишка здесь в автономности: достаточно дать инструкцию, и Goose сам проходит весь пайплайн от отладки кода и разработки фич до финального деплоя.

При этом Goose может целиком работать локально, поддерживает подключение любого LLM и протокол MCP, что дает приватность данных и высокую расширяемость.

Есть готовые установочные пакеты: скачиваешь с сайта или со страницы Releases, настраиваешь API Key провайдера модели и можно пользоваться.

Уже немало инженеров применяют его в реальных проектах. Если хочется разгрузиться от рутины и повторяющихся задач, это AI-инструмент, который стоит попробовать.

Cсылка на GitHub

➡️ GitHub Ready | #урок