🤩 Шаблон для запуска локальных ИИ в одном пакете

Проект из репо Self-hosted AI Package представлен в виде файла Docker-compose, который уже настроен для сети и диска.

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

Ссылка

➡️ GitHub Ready | #урок

⚙️ Git Reflog — восстановление потерянных коммитов

git reflog показывает историю перемещений HEAD, даже если коммиты исчезли из ветки.

Просмотр истории:

git reflog

Найти нужный хеш:

git reflog --oneline

Вернуться к состоянию:

git reset --hard <hash>

Создать ветку из прошлого состояния:

git checkout -b restore-branch <hash>

Когда применять:
• случайный reset --hard;
• удаление ветки;
• потерянный commit после rebase.

reflog хранит локальную историю действий — пока объект не удалён сборщиком мусора, его можно вернуть.

➡️ GitHub Ready | #урок

🧹 Как удалить ветки, которых больше нет на сервере?

Со временем локальный список веток забивается «мусором» — ветками, которые уже слиты и удалены из удаленного репозитория (origin). Обычный git pull их не чистит.

Задача:

* Синхронизировать список веток с сервером.
* Удалить локальные ссылки на несуществующие удаленные ветки.

Решение:

Используем команду fetch с флагом --prune (или -p), которая подчистит все устаревшие ссылки:

# Очистить ссылки на удаленные ветки
git fetch --prune

# Сделать это поведение автоматическим для всех будущих pull
git config --global fetch.prune true

Что это дает?
Команда удаляет только "remote-tracking" ветки (те, что видны как origin/branch-name). Это делает вывод git branch -a чистым и актуальным, избавляя тебя от путаницы в истории.

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

➡️ GitHub Ready | #совет

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

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

Задача:

* Сохранить текущие правки во временном хранилище.
* Вернуть рабочую директорию к чистому состоянию для переключения веток.

Решение:

Используем команду stash. Она как «карман», куда можно быстро положить изменения:

# Спрятать все текущие изменения (staged и unstaged)
git stash

# Спрятать изменения и дать им имя (чтобы не запутаться)
git stash save "Работа над хедером"

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

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

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

Почему это удобно?
Тебе не нужно создавать «мусорные» коммиты вроде "temp" или "WIP", которые потом придется склеивать. Ты просто откладываешь работу в сторону и возвращаешься к ней, когда удобно.

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

➡️ GitHub Ready | #совет

🔍 Как найти коммит, который сломал код? (Git Bisect)

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

Задача:

* Максимально быстро найти конкретный коммит, внесший ошибку.
* Автоматизировать процесс поиска.

Решение:

Команда bisect делит историю пополам, пока не вычислит «виновника»:

# Начинаем процесс
git bisect start

# Помечаем текущее состояние как плохое
git bisect bad

# Помечаем старый хэш (или тег), где всё точно работало, как хорошее
git bisect good <commit-hash>

# Git переключит тебя на коммит посередине. Проверь код:
# Если баг есть: git bisect bad
# Если бага нет: git bisect good

# Когда Git найдет коммит, заверши поиск:
git bisect reset

Почему это круто?
Вместо проверки 100 коммитов по порядку, тебе понадобится всего около 7 шагов (так работает бинарный поиск). Это самый эффективный способ диагностики в больших проектах.

🔥 — если знал про этот метод
🤝 — если ищешь баги «руками» через лог

➡️ GitHub Ready | #совет

🧩 Как объединить несколько коммитов в один? (Git Squash)

Бывает, что за день ты наплодил кучу мелких коммитов вроде "fix", "typo", "debug". В историю проекта такое пускать стыдно — лучше объединить их в один логичный и красивый коммит перед мержем.

Задача:

* Навести порядок в истории ветки.
* Превратить цепочку мелких правок в один осмысленный коммит.

Решение:

Используем интерактивный ребейз (interactive rebase) для последних N коммитов (например, трех):

# Запускаем интерактивный режим для 3 последних коммитов
git rebase -i HEAD~3

В открывшемся текстовом редакторе ты увидишь список коммитов. Замени слово pick на squash (или просто s) у тех коммитов, которые нужно «влить» в предыдущий:

pick e3a1b2c Добавил логику корзины
squash a5b6c7d fix: исправил опечатку
squash 9f8e7d6 debug: удалил console.log

После сохранения Git предложит тебе отредактировать финальное сообщение для объединенного коммита.

Почему это важно?
Чистая история (Git History) — это признак профессионализма. Коллегам будет гораздо проще делать Code Review, если они увидят одну четкую задачу вместо десяти правок в одну строчку.

🔥 — если всегда сквашиваешь перед мержем
🤝 — если оставляешь историю как есть

➡️ GitHub Ready | #совет

📁 Как закоммитить только часть файла? (Git Add -p)

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

Задача:

* Выбрать конкретные строки или блоки кода внутри одного файла для коммита.
* Оставить остальные изменения в статусе "unstaged" для следующего раза.

Решение:

Используем флаг --patch (или -p) при добавлении файлов в индекс:

# Git покажет каждый кучок изменений и спросит, что с ним делать
git add -p path/to/file.txt

Основные команды в режиме патча:

* y (yes) — добавить этот блок в индекс.
* n (no) — пропустить этот блок.
* s (split) — разбить блок на еще более мелкие части.
* q (quit) — выйти и сохранить то, что уже выбрано.

Почему это полезно?
Это заставляет тебя еще раз просмотреть свой код перед коммитом (само-ревью). Ты точно не закоммитишь лишние console.log или временные заметки, которые случайно остались в файле.

🔥 — если коммитишь атомарно по кусочкам
🤝 — если всегда добавляешь файл целиком через git add .

➡️ GitHub Ready | #совет

🏷️ Как работать с тегами (Git Tag)

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

Задача:

* Отметить конкретный коммит как важную веху (v1.0, v2.4.0).
* Быстро возвращаться к стабильным версиям кода.

Решение:

Создаем «аннотированный» тег (с сообщением и автором), так как это стандарт для релизов:

# Создать тег для текущего коммита
git tag -a v1.0.0 -m "Релиз первой версии"

# Посмотреть список всех тегов
git tag

# Отправить теги на удаленный сервер (по умолчанию push их не берет)
git push origin --tags

# Переключиться на код конкретной версии
git checkout v1.0.0

В чем разница с ветками?
Ветка — это указатель, который двигается вперед с каждым новым коммитом. Тег — это статичная метка. Он «прилипает» к конкретному хэшу и никогда не меняется. Это идеальный способ заморозить состояние кода для истории.

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

➡️ GitHub Ready | #совет

🔍 Как найти коммит по тексту в коде? (Git Grep)

Бывает, что ты помнишь название удаленной функции или старый API-ключ, но не знаешь, в каком коммите они были удалены или изменены. Листать git log можно бесконечно, но есть способ быстрее.

Задача:

* Найти все упоминания строки во всей истории проекта.
* Понять, когда конкретный текст появился или исчез из кода.

Решение:

Используем команду grep, встроенную в Git. Она ищет гораздо быстрее обычного поиска по файлам, так как работает напрямую с базой данных Git:

# Искать текст во всех файлах в текущем состоянии
git grep "название_функции"

# Найти коммиты, в которых эта строка была добавлена или удалена (History Search)
git log -S "название_функции"

# Посмотреть изменения (diff) для каждого найденного случая
git log -S "название_функции" -p

Почему это удобно?
Флаг -S (так называемый "Pickaxe") ищет именно изменения в количестве вхождений строки. Если функция была добавлена — она попадет в поиск. Если была полностью удалена — тоже. Это незаменимо при расследовании того, "куда делся этот кусок кода".

🔥 — если знал про «кирку» (Pickaxe)
🤝 — если ищешь через Ctrl+F по всему проекту

➡️ GitHub Ready | #совет

📋 Как создать свои команды в Git? (Git Aliases)

Если тебе надоело каждый раз вводить длинные команды вроде git checkout или git commit -v, ты можешь создать короткие псевдонимы (алиасы). Это экономит кучу времени и делает работу в терминале приятнее.

Задача:

* Сократить часто используемые команды до 2–3 букв.
* Создать сложные цепочки команд под одним коротким именем.

Решение:

Алиасы настраиваются через git config. Вот самые популярные и полезные настройки:

# Сокращаем стандартные команды
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

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

# Алиас для отмены последнего коммита с сохранением изменений
git config --global alias.unstage "reset HEAD --"

Как это использовать?
Теперь вместо git checkout master ты пишешь просто git co master. А команда git lg покажет тебе наглядную структуру всех веток и коммитов прямо в консоли.

Почему это важно?
Автоматизация рутины — ключ к продуктивности. Ты можешь настроить Git «под себя», превратив его в удобный инструмент, который понимает тебя с полуслова.

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

➡️ GitHub Ready | #совет

🛠 Как изменить сообщение последнего коммита? (Git Amend)

Опечатался в тексте коммита или забыл добавить один файл в индекс? Не нужно делать новый «fix»-коммит. Можно просто исправить последний, пока он еще не улетел на сервер.

Задача:

* Исправить текст последнего сообщения.
* Добавить забытые изменения в предыдущий коммит.

Решение:

Используем флаг --amend. Он берет текущее состояние индекса и «склеивает» его с последним коммитом, позволяя заодно поменять описание:

# Если нужно просто изменить текст сообщения:
git commit --amend -m "Новое правильное сообщение"

# Если забыл добавить файл:
git add forgotten_file.js
git commit --amend --no-edit

> Важно: Используй это только для локальных коммитов. Если ты уже сделал push, amend изменит хэш коммита, и при следующей отправке возникнет конфликт историй.

Почему это полезно?
История остается чистой, без лишнего шума из мелких правок и исправлений опечаток. Твой репозиторий выглядит аккуратно, а коллеги видят только готовый результат.

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

➡️ GitHub Ready | #совет

🚀 Быстрый переход между ветками (Git Checkout -)

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

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

Решение:

Используй символ тире после команды перехода:

# Переключиться на предыдущую активную ветку
git checkout -

# В современных версиях Git работает и для switch:
git switch -

Почему это удобно?
— Скорость: переключение происходит за доли секунды.
— Точность: нет риска опечататься в названии ветки.
— Удобство: команда работает по аналогии с cd - в терминале, которая возвращает в предыдущую директорию.

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

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

➡️ GitHub Ready | #совет

🛡️ Как защитить важные ветки? (Git Read-only)

Бывает, что по ошибке можно отправить (push) сырой код прямо в main или develop, сломав билд всей команде. Чтобы этого не случилось, стоит настроить защиту веток.

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

Решение:

Хотя базовый Git не имеет встроенной блокировки "из коробки" для локальной работы, на всех популярных хостингах (GitHub, GitLab, Bitbucket) это настраивается в пару кликов:

— GitHub: Settings → Branches → Add branch protection rule.
— GitLab: Settings → Repository → Protected branches.

Что обычно включают в защиту:
— Require a pull request before merging: никто не может пушить код напрямую, только через PR.
— Require status checks to pass: автотесты и линтеры должны пройти успешно перед слиянием.
— Restrict who can push: только тимлиды или релиз-инженеры имеют право на прямые правки.

Почему это важно?
Это дисциплинирует команду и страхует от случайных ошибок. Твоя основная ветка всегда остается стабильной, а история — чистой и проверенной.

🔥 — если у вас всё под защитой
🤝 — если доверяете друг другу на слово

➡️ GitHub Ready | #совет

🔒 Как скрыть конфиденциальные данные? (Git-crypt)

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

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

Решение:

Используем стороннюю утилиту git-crypt. Она интегрируется с Git и автоматически шифрует файлы при коммите и расшифровывает при чекауте:

# Инициализировать шифрование в проекте
git-crypt init

# Указать файлы для шифрования в .gitattributes
# secret_config.json filter=git-crypt diff=git-crypt

# Экспортировать ключ для коллег
git-crypt export-key /path/to/keyfile

# Расшифровать репозиторий на другой машине
git-crypt unlock /path/to/keyfile

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

Это профессиональный стандарт для хранения секретов, если вы не используете внешние системы вроде Vault или AWS Secrets Manager.

🔥 — если шифруете важные данные
🤝 — если храните всё в переменных окружения (.env)

➡️ GitHub Ready | #совет

🕒 Как посмотреть историю изменений конкретного файла?

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

Задача:
— Просмотреть список коммитов, затрагивающих конкретный файл.
— Увидеть изменения в коде (diff) для каждой версии этого файла.

Решение:

Используем команду log с указанием пути к файлу:

# Показать историю коммитов только для этого файла
git log path/to/file.js

# Показать историю с изменениями кода внутри каждого коммита
git log -p path/to/file.js

# Показать краткую статистику (сколько строк добавлено/удалено)
git log --stat path/to/file.js

Почему это полезно?
— Фокус: ты не тонешь в общем потоке изменений.
— Контекст: легко отследить логику развития конкретной функции или класса.
— Скорость: поиск по конкретному пути работает быстрее, чем по всему репозиторию.

Если файл был переименован, добавь флаг --follow, чтобы Git продолжил отслеживать историю файла до момента его переименования.

🔥 — если часто изучаешь историю файлов
🤝 — если смотришь историю только через интерфейс GitHub/GitLab

➡️ GitHub Ready | #совет

🧹 Как отменить изменения в файле? (Git Restore)

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

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

Решение:

Раньше для этого использовали запутанный git checkout -- file, но теперь есть restore:

# Отменить изменения в конкретном файле
git restore path/to/file.js

# Вернуть сразу все измененные файлы в папке к исходному виду
git restore .

# Вытащить файл из индекса (сделать unstage), если уже сделал git add
git restore --staged path/to/file.js

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

Это самый быстрый способ очистить рабочее пространство от неудачных экспериментов.

🔥 — если уже перешел на restore
🤝 — по привычке используешь checkout или reset

➡️ GitHub Ready | #совет

🔄 Как быстро переименовать локальную ветку?

Иногда в спешке создаешь ветку с опечаткой или понимаешь, что название fix-1 совсем не отражает суть задачи. В Git можно легко переименовать ветку, не удаляя её.

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

Решение:

Для этого используется флаг -m (move):

# Переименовать текущую ветку, на которой ты находишься
git branch -m новое-название

# Переименовать любую другую ветку
git branch -m старое-название новое-название

Если ветка уже улетела на сервер (push):
— Переименуй её локально (как показано выше).
— Удали старую ветку на сервере: git push origin --delete старое-название.
— Запушь новую ветку и свяжи её с удаленной: git push origin -u новое-название.

Почему это важно?
— Порядок: понятные названия веток облегчают навигацию.
— Командная работа: коллегам проще ориентироваться в Pull Request, когда название ветки соответствует задаче.
— Автоматизация: многие CI/CD системы опираются на префиксы в названиях (например, feature/ или hotfix/).

🔥 — если всегда даешь веткам осмысленные имена
🤝 — если до сих пор работаешь в task-123

➡️ GitHub Ready | #урок