Yаzi

Высокопроизводительный файловый менеджер для терминала

Yаzi — это терминальный файловый менеджер, написанный на Rust и построенный на неблокирующем асинхронном вводе-выводе. Он ориентирован на скорость, удобство и гибкую настройку при работе с файлами прямо из консоли.

Возможности:

• Поддержка нескольких форматов изображений из коробки
• Полностью асинхронная архитектура: все I/O-операции выполняются асинхронно, а CPU-задачи распределяются по потокам для максимальной производительности
• Встроенная подсветка кода
• Интеграция с fd, ripgrep, fzf, zoxide
• Управление в стиле Vim
• Работа с несколькими вкладками
• Предпросмотр с прокруткой для видео, PDF, архивов, каталогов, исходного кода и других типов файлов
• Темы оформления, пользовательские раскладки, корзина для удалённых файлов
• Дополнительные функции для кастомизации и удобной навигации

Открыть

➡️ GitHub Ready | #урок

Howdy

Для Linux существует проект Howdy — он добавляет аутентификацию по распознаванию лица, аналогичную Windows Hello. Программа использует камеру и ИК-излучатели для быстрого и безопасного входа в систему.

Howdy работает через PAM, поддерживает экран логина и выполнение sudo. Совместим с Debian/Ubuntu, Arch Linux, Fedora и openSUSE. Подходит тем, кто хочет отказаться от паролей и использовать биометрическую аутентификацию в Linux.

GitHub

➡️ GitHub Ready | #урок

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

Иногда ветка удалена или коммит кажется потерянным. git reflog хранит историю всех перемещений HEAD, и это твой путь к восстановлению.
• Просмотреть историю перемещений HEAD:

git reflog

• Вернуть ветку или коммит в рабочее состояние:

git checkout <hash_коммита>

• Восстановить удалённую ветку:

git branch feature/rescue <hash_коммита>

💡 Даже если кажется, что работа потеряна, reflog часто спасает ситуацию без стресса.

➡️ GitHub Ready | #урок

📌 Что такое git rebase и зачем он нужен на практике

git rebase — инструмент для переписывания истории коммитов. Он переносит ваши коммиты поверх другой ветки, делая историю линейной и читаемой.

Базовый сценарий:

git checkout feature
git rebase main

Что происходит:
• коммиты из feature временно убираются;
• ветка обновляется до состояния main;
• коммиты применяются заново поверх неё.

Полезно, когда:

• нужно подтянуть свежие изменения без лишних merge-коммитов;
• хочешь аккуратную историю в pull request;
• работаешь в команде с жёсткими требованиями к логам.

Важно:

• не делай rebase публичных веток;
• если возник конфликт — правишь файлы и продолжаешь:

git rebase --continue

rebase — не про магию, а про контроль и порядок в истории проекта.

➡️ GitHub Ready | #урок

🛠 Git Stash — временное сохранение изменений

Иногда нужно переключиться на другую ветку, но текущие изменения не готовы к коммиту. git stash временно сохраняет работу, не создавая лишних коммитов.
• Сохранить изменения:

git stash

• Посмотреть список сохранённых изменений:

git stash list

• Вернуть последние сохранённые изменения:

git stash pop

• Применить изменения без удаления из списка:

git stash apply

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

➡️ GitHub Ready | #урок

📂 Как работает .gitignore и почему он не игнорирует файлы

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

Частая ошибка:
• файл уже закоммичен;
• добавляешь его в .gitignore;
• Git продолжает его видеть.

Правильное решение:

git rm --cached config.env

После этого файл:
• останется на диске;
• перестанет отслеживаться;
• начнёт игнорироваться по правилам .gitignore.

Проверить, почему файл не игнорируется:

git check-ignore -v config.env

.gitignore — это фильтр для новых файлов, а не кнопка «скрыть всё».

➡️ GitHub Ready | #урок

🧠 Зачем нужен git blame и как читать его правильно

git blame показывает, какой коммит и какой автор последний раз менял каждую строку файла. Инструмент для понимания контекста, а не для поиска виноватых.

Базовое использование:

git blame app.js

Полезные флаги:
• Игнорировать переносы строк и форматирование:

git blame -w app.js

• Показать историю конкретного диапазона строк:

git blame -L 20,40 app.js

Переход к коммиту строки:
• копируешь hash;
• смотришь изменения:

git show <hash>

git blame отвечает на три вопроса: что изменили, когда и зачем.

➡️ GitHub Ready | #урок

🔀 Merge commit vs Fast-forward — в чём разница

При слиянии веток Git может использовать разные стратегии. Понимание разницы важно для чистой истории.

Fast-forward merge
Происходит, если основная ветка не менялась.
• Git просто сдвигает указатель ветки;
• история остаётся линейной;

git merge feature

Merge commit
Создаётся отдельный коммит слияния.
• сохраняет факт объединения веток;
• полезно для больших фич;

git merge --no-ff feature

Когда что использовать:
• fast-forward — мелкие правки, простые фичи;
• merge commit — командная работа, долгие ветки.

Стратегия влияет не на код, а на читаемость истории проекта.

➡️ GitHub Ready | #урок

🧪 Git Bisect — поиск бага бинарным поиском

git bisect помогает найти коммит, в котором появился баг, без ручного перебора истории. Git сам делит диапазон коммитов пополам.

Запуск:

git bisect start
git bisect bad        # текущий коммит с багом
git bisect good v1.2  # версия, где всё работало

Дальше Git:
• переключает коммиты;
• ты проверяешь баг;
• помечаешь результат:

git bisect good
git bisect bad

Завершение:

git bisect reset

Итог:
• точный коммит с поломкой;
• минимум проверок;
• идеально для сложных багов, появившихся «где-то в истории».

➡️ GitHub Ready | #урок

🔐 Подпись коммитов в Git — зачем и как использовать

Подписанные коммиты подтверждают, что изменения действительно сделаны автором, а не подменены. Часто требуются в open-source и корпоративных репозиториях.

Проверка подписи коммита:

git log --show-signature

Подпись каждого коммита:

git config --global commit.gpgsign true

Одноразовая подпись:

git commit -S -m "fix: auth logic"

Что это даёт:
• подтверждение авторства;
• защита от подмены;
• доверие к истории репозитория.

Подпись коммитов — это не паранойя, а контроль целостности кода.

➡️ GitHub Ready | #урок

📦 Git Submodule — подключение одного репозитория к другому

git submodule позволяет использовать внешний репозиторий как часть основного проекта, фиксируя конкретную версию кода.

Добавление сабмодуля:

git submodule add https://github.com/lib/example.git libs/example

Инициализация и загрузка:

git submodule update --init --recursive

Обновление сабмодулей:

git submodule update --remote

Важно помнить:
• сабмодуль — это отдельный Git-репозиторий;
• в основном проекте хранится ссылка на конкретный коммит;
• изменения в сабмодуле нужно коммитить отдельно.

Submodule — инструмент для строгого контроля зависимостей, а не для удобства.

➡️ GitHub Ready | #урок

📊 Git Cherry-pick — перенос одного коммита без всей ветки

git cherry-pick позволяет взять конкретный коммит и применить его в другой ветке, не делая merge или rebase всей истории.

Базовое использование:

git cherry-pick <hash>

Перенос диапазона коммитов:

git cherry-pick <hash1>..<hash2>

Если возник конфликт:

git cherry-pick --continue

Отмена операции:

git cherry-pick --abort

Когда полезно:
• срочный хотфикс в main;
• перенос одной фичи без лишних изменений;
• аккуратная работа с релизными ветками.

cherry-pick — точный инструмент, требует аккуратности.

➡️ GitHub Ready | #урок

⚙️ Git Hooks — автоматизация до и после команд Git

Git hooks — это скрипты, которые автоматически запускаются при определённых действиях: коммит, push, merge и т.д. Используются для контроля качества и автоматизации.

Где находятся:

.git/hooks/

Примеры хуков:
• pre-commit — запуск линтера, тестов;
• commit-msg — проверка формата сообщения;
• pre-push — блокировка push при ошибках.

Простейший pre-commit:

#!/bin/sh
npm test || exit 1

Важно:
• хуки не коммитятся по умолчанию;
• для команды используют шаблоны или husky;
• экономят время и ловят ошибки раньше CI.

Git hooks — локальный CI до настоящего CI.

➡️ GitHub Ready | #урок

🧬 Detached HEAD — что это и почему это нормально

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

Пример:

git checkout a1b2c3d

Что происходит:
• HEAD указывает прямо на коммит;
• новые коммиты не принадлежат ни одной ветке;
• при переключении ветки они могут «потеряться».

Как сохранить работу:

git switch -c fix-from-old-commit

Когда это полезно:
• анализ старого состояния проекта;
• тестирование прошлых версий;
• быстрые эксперименты без влияния на ветки.

Detached HEAD — это режим просмотра и экспериментов, а не ошибка.

➡️ GitHub Ready | #урок

📈 Git Squash — объединение коммитов перед merge

Squash позволяет превратить несколько рабочих коммитов в один аккуратный перед добавлением в основную ветку.

Через интерактивный rebase:

git rebase -i HEAD~3

В списке:
• первый коммит — pick;
• остальные меняешь на squash или s.

После этого:
• объединяются изменения;
• редактируется одно итоговое сообщение коммита;
• история становится чище.

Когда использовать:
• много мелких «fix», «wip»;
• подготовка PR;
• требования к чистой истории.

Squash — порядок в истории без потери смысла изменений.

➡️ GitHub Ready | #урок

🧾 Conventional Commits — зачем нужен единый формат коммитов

Conventional Commits — соглашение о структуре сообщений коммитов, которое упрощает навигацию по истории и автоматизацию релизов.

Формат:

type(scope): краткое описание

Примеры:

feat(auth): add token refresh
fix(ui): fix modal closing bug
refactor(api): simplify handlers

Что это даёт:
• читаемая история;
• автоматический changelog;
• корректный semver;
• проще код-ревью.

Conventional Commits — фундамент для масштабируемой разработки.

➡️ GitHub Ready | #урок

🗂 Git Worktree — несколько рабочих копий одного репозитория

git worktree позволяет иметь несколько рабочих директорий для одного репозитория без лишних clone.

Добавить новую рабочую копию:

git worktree add ../hotfix main

Список worktree:

git worktree list

Удаление:

git worktree remove ../hotfix

Когда полезно:
• параллельная работа над фичей и хотфиксом;
• тестирование разных веток одновременно;
• экономия места и времени.

worktree — альтернатива постоянным stash и переключениям веток.

➡️ GitHub Ready | #урок

🧭 Git HEAD — что это и как он управляет репозиторием

HEAD — указатель на текущее состояние репозитория. Обычно он указывает на ветку, а ветка — на последний коммит.

Проверить, куда указывает HEAD:

cat .git/HEAD

Типичные случаи:
• HEAD -> main — нормальная работа;
• HEAD -> feature — работа в фиче-ветке;
• HEAD detached — HEAD указывает прямо на коммит.

Перемещение HEAD:

git checkout HEAD~1

Важно:
• коммиты всегда создаются там, куда указывает HEAD;
• понимание HEAD = меньше «магии» в Git;
• большинство ошибок — это потерянный контекст HEAD.

Git становится простым, когда ясно, куда смотрит HEAD.

➡️ GitHub Ready | #урок

🧩 Git Reset — чем отличаются --soft, --mixed, --hard

git reset перемещает HEAD и по-разному влияет на индекс и рабочую директорию. Ошибки здесь самые дорогие, поэтому важно понимать разницу.

--soft

git reset --soft HEAD~1

• сдвигает HEAD;
• индекс и файлы не трогает;
• коммит «отменён», изменения готовы к новому коммиту.

--mixed (по умолчанию)

git reset HEAD~1

• сдвигает HEAD;
• очищает индекс;
• файлы остаются изменёнными.

--hard

git reset --hard HEAD~1

• сдвигает HEAD;
• очищает индекс;
• удаляет изменения в файлах.

reset — инструмент контроля, а не отката «наугад».

➡️ GitHub Ready | #урок

💡 Git Diff — сравниваем изменения на лету

git diff показывает, что изменилось между коммитами, ветками или рабочей директорией.

Примеры использования:
• Изменения в рабочей директории перед коммитом:

git diff

• Изменения между индексом и последним коммитом:

git diff --cached

• Сравнение двух веток:

git diff main..feature

• Конкретного файла:

git diff HEAD~1 README.md

💡 Полезно для проверки работы перед коммитом и анализа истории без открытия внешних инструментов.

➡️ GitHub Ready | #урок

🧠 Git Config — управление поведением Git

git config отвечает за настройки Git: от имени автора до стратегий слияния. Понимание уровней конфигурации избавляет от неожиданных эффектов.

Уровни конфигурации:
• --system — для всей системы;
• --global — для пользователя;
• --local — для конкретного репозитория.

Примеры:

git config --global user.name "Nadir"
git config --global user.email "mail@example.com"

Посмотреть все активные настройки:

git config --list --show-origin

Удалить параметр:

git config --unset user.name

git config — это не разовая команда, а фундамент стабильной работы с Git.

➡️ GitHub Ready | #урок