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

Иногда в процессе работы над фичей получается гора мелких коммитов типа «fix», «typo» или «test». Чтобы не пугать коллег грязной историей в общем репозитории, их лучше объединить в один логичный и красивый коммит перед слиянием.

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

Решение:

Самый гибкий способ — это интерактивный ребейз (interactive rebase).

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

# 2. В открывшемся текстовом редакторе ты увидишь список коммитов.
# Замени слово 'pick' на 'squash' (или просто 's') у тех коммитов, 
# которые хочешь присоединить к предыдущему:

pick a1b2c3d Добавил логику входа
squash b2c3d4e Исправил опечатку в логине
squash c3d4e5f Добавил тесты для валидации

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

Почему это важно?
— Читаемость: в истории остаются только важные этапы разработки.
— Удобство отката: если фича сломала билд, её можно отменить одним revert, а не искать все 20 мелких правок.
— Профессионализм: чистый Git-лог — признак высокого качества работы над проектом.

Важно: Как и с любым ребейзом, делай это только с локальными коммитами, которые ты еще не отправлял в общую ветку.

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

➡️ GitHub Ready | #урок

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

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

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

Решение:

Для этого существует команда «выбора вишенки» — cherry-pick. Она берет изменения из указанного коммита и создает их точную копию в твоей ветке.

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

# 2. Примени нужный коммит по его хэшу
git cherry-pick a1b2c3d

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

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

Важно: Помни, что cherry-pick создает новый коммит с новым хэшем. Если ты потом решишь слить ветки целиком, Git поймет, что эти изменения уже есть, и не будет создавать дублей (в большинстве случаев).

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

➡️ GitHub Ready | #урок

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

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

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

Решение:

Используем команду stash, которая сохраняет текущее состояние в специальный временный стек.

# 1. Спрятать все текущие изменения (включая индекс)
git stash

# 2. Дать заначке имя, чтобы не запутаться (рекомендуется)
git stash save "Работа над валидацией форм"

# 3. Посмотреть список всех отложенных правок
git stash list

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

# 5. Применить изменения, но оставить их в стеке (на всякий случай)
git stash apply stash@{0}

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

Важно: По умолчанию stash не берет новые (untracked) файлы. Чтобы спрятать и их, добавь флаг -u.

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

➡️ GitHub Ready | #урок

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

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

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

Решение:

Теги бывают легковесными (просто указатель) и аннотированными (полноценный объект с автором и датой). Лучше всегда использовать аннотированные.

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

# Создать тег для коммита, который был в прошлом (по хэшу)
git tag -a v0.9.5 5f3a2b1

# Отправить теги на сервер (обычный push их не переносит)
git push origin v1.0.0
# Или отправить сразу все локальные теги
git push origin --tags

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

Почему это удобно?
— Стандартизация: теги позволяют легко интегрироваться с системами сборки и авто-релизами на GitHub/GitLab.
— Навигация: вместо того чтобы искать хэш коммита в логах, ты просто переключаешься на v2.1.0.
— Долговечность: в отличие от веток, теги не меняются и всегда указывают на один и тот же коммит.

Если тебе нужно скачать код конкретной версии, ты можешь просто сделать git checkout v1.0.0. Git перейдет в состояние "detached HEAD", что идеально подходит для сборки проекта.

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

➡️ GitHub Ready | #урок

Обратная сторона Windows 😂

➡️ GitHub Ready | #урок

🔍 Как найти коммит по сообщению? (Git Log Grep)

Бывает, что ты помнишь: месяц назад кто-то фиксил баг с авторизацией или добавлял интеграцию со Stripe. Ты не помнишь ни хэша, ни ветки, ни точной даты. Листать git log вручную — задача для очень терпеливых. Но в Git есть встроенный поиск по сообщениям.

Задача:
— Быстро найти все коммиты, в описании которых есть ключевое слово.
— Отфильтровать историю по конкретной задаче из Jira или Trello.

Решение:

Используем команду log с флагом --grep:

# Найти все коммиты, где в описании упоминается "auth"
git log --grep="auth"

# Искать без учета регистра (Auth, AUTH, auth)
git log -i --grep="auth"

# Поиск по нескольким словам (найдет коммиты, где есть либо "fix", либо "bug")
git log --grep="fix" --grep="bug"

# Показать только хэш и первую строку сообщения для компактности
git log --grep="stripe" --oneline

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

Совет: Если ты ищешь не в сообщении, а в самом коде (кто вписал это слово в файл?), используй git grep "слово". А если нужно найти, когда это слово *появилось* или *исчезло* из кода — используй «поиск-кирку»: git log -S "слово".

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

➡️ GitHub Ready | #урок

🕵️ Как найти, где в коде появилось или исчезло слово? (Git Log -S)

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

Задача:
— Найти все коммиты, в которых количество упоминаний строки изменилось (добавили или удалили).
— Отследить судьбу конкретной переменной или метода через всю историю проекта.

Решение:

Используем так называемый «поиск-кирку» (pickaxe search) с флагом -S:

# Найти коммиты, где добавляли или удаляли строку "calculateTotal"
git log -S "calculateTotal"

# Посмотреть сразу с изменениями кода (diff) внутри найденных коммитов
git log -S "calculateTotal" -p

# Если нужно найти строку по регулярному выражению
git log -G "api_key_[0-9]+"

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

Важно: Флаг -S сработает только если количество упоминаний строки изменилось. Если ты просто перенес строку из одного места в другое внутри того же коммита, используй -G.

🔥 — если чувствуешь себя детективом, используя -S
🤝 — если просто ищешь по файлам через VS Code

➡️ GitHub Ready | #урок

⏱ Как узнать, на что уходит время? (Git Log --since)

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

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

Решение:

Используем флаги --since (с тех пор) и --until (до тех пор). Git понимает даже человекоподобные форматы дат:

# Показать коммиты за последние две недели
git log --since="2 weeks ago"

# Посмотреть, что было сделано с начала вчерашнего дня
git log --since="yesterday"

# Выгрузить активность за конкретный период (например, за прошлый месяц)
git log --since="2026-02-01" --until="2026-02-28" --oneline

# Коммиты конкретного автора за последнюю неделю
git log --since="1 week ago" --author="Ivan"

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

Совет: Если добавить флаг --no-merges, Git скроет технические коммиты о слиянии веток, и в списке останутся только твои реальные изменения.

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

➡️ GitHub Ready | #урок

📊 Как получить статистику по репозиторию? (Git Shortlog)

Когда проект длится долго, бывает интересно взглянуть на него с высоты птичьего полета: кто внес больше всего вклада, сколько коммитов было сделано за все время и как распределяется работа между участниками команды.

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

Решение:

Команда shortlog создана специально для обобщения истории. Она группирует коммиты по авторам и выводит их в алфавитном порядке.

# Показать авторов и заголовки их коммитов
git shortlog

# Вывести только количество коммитов для каждого автора (summary)
git shortlog -s

# Отсортировать список по количеству коммитов (от самых активных к менее)
git shortlog -s -n

# Посмотреть статистику только за последнюю неделю
git shortlog -s -n --since="1 week ago"

Почему это полезно?
— Аналитика: сразу видно, кто «владеет» кодовой базой или кто активнее всех участвует в спринте.
— Подготовка релизов: флаг -s помогает быстро составить список контрибьюторов для Changelog.
— Оценка нагрузки: если один человек делает 90% коммитов, возможно, стоит перераспределить задачи.

Совет: Если один и тот же человек отображается под разными именами (например, из-за разных конфигов на домашнем и рабочем ПК), это можно исправить с помощью файла .mailmap в корне проекта.

🔥 — если следишь за статистикой команды
🤝 — если тебе не важно количество, главное — качество

➡️ GitHub Ready | #урок

🔍 Как найти коммит, в котором изменилась конкретная функция? (Git Log -L)

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

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

Решение:

Используем флаг -L. Он позволяет указать имя функции и файл, в котором она находится. Git сам поймет, где она начинается и заканчивается.

# Синтаксис: git log -L :имя_функции:путь_к_файлу
git log -L :calculateTotal:src/utils/cart.js

# Если нужно отследить конкретный диапазон строк (например, с 15 по 30)
git log -L 15,30:src/utils/cart.js

Почему это эффективнее обычного лога?
— Фокус: ты видишь только те коммиты, которые реально затронули код внутри этой функции.
— Наглядность: Git сразу показывает diff (разницу) для каждого изменения, так что ты видишь, как трансформировались аргументы или условия.
— Интеллект: даже если ты переименовал файл или передвинул функцию выше по коду, Git (в большинстве случаев) не потеряет след.

Это незаменимый инструмент для рефакторинга: прежде чем переписывать старый метод, посмотри, через какие «боли» он прошел за последние полгода.

🔥 — если копаешь историю до самого основания
🤝 — если просто смотришь последний коммит через аннотации в IDE

➡️ GitHub Ready | #урок

🚦 Как проверить, какие коммиты есть в одной ветке, но нет в другой? (Git Log A..B)

Частая ситуация перед мержем: тебе нужно понять, что именно ты сейчас собираешься влить из feature-ветки в main. Или наоборот — хочешь проверить, насколько твоя локальная ветка отстала от сервера.

Задача:
— Увидеть список изменений, которые есть в «источнике», но отсутствуют в «цели».
— Убедиться, что в ветку не попало ничего лишнего перед отправкой Pull Request.

Решение:

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

# Показать коммиты, которые есть в feature-branch, но нет в main
git log main..feature-branch

# Самый частый кейс: что я накодил относительно мастера?
git log master..HEAD --oneline

# Что нового появилось на сервере, чего у меня еще нет?
# (После git fetch)
git log HEAD..origin/main

# Если хочешь посмотреть не только список, но и сам код
git log -p main..feature-branch

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

Совет: Если использовать три точки (A...B), Git покажет коммиты, которые есть в любой из этих веток, но отсутствуют в их общем предке (симметрическая разность). Это помогает понять, насколько сильно разошлись пути двух разработчиков.

🔥 — если всегда проверяешь дифф перед мержем
🤝 — если доверяешь кнопке "Merge" на GitHub

➡️ GitHub Ready | #урок

🌳 Как увидеть дерево проекта прямо в консоли? (Git Log --graph)

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

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

Решение:

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

# Базовая команда для отрисовки дерева
git log --graph --oneline --all

# "Золотой стандарт" alias (красиво и с цветами):
git log --graph --pretty=format:'%C(auto)%h %C(magenta)%ad %C(cyan)%an %C(auto)%d %s' --date=short --all

Почему это удобно?
— Наглядность: ты видишь «щупальца» веток и точки их слияния (merge commits).
— Скорость: не нужно открывать GitKraken или Sourcetree, чтобы быстро прикинуть состояние репозитория.
— Контроль: сразу заметно, если кто-то забыл сделать rebase или наплодил лишних мержей.

Разбор флагов:
— --graph — рисует текстовую схему слева.
— --oneline — компактно умещает один коммит в одну строку.
— --all — показывает вообще все ветки (и локальные, и удаленные), а не только текущую.
— --decorate — подсвечивает названия веток и теги рядом с коммитами.

🔥 — если твой терминал всегда выглядит как матрица
🤝 — если предпочитаешь смотреть граф в GitHub Desktop

➡️ GitHub Ready | #урок

⌨️ Как ускорить работу с Git? (Git Aliases)

Если тебе надоело каждый раз вводить длинные команды вроде git log --graph --oneline --all, пришло время настроить алиасы. Это короткие псевдонимы, которые экономят время и превращают работу в терминале в удовольствие.

Задача:
— Сократить часто используемые команды до 2–3 букв.
— Создать свои собственные «супер-команды» со сложными флагами.
— Перестать ошибаться в длинных словах типа checkout.

Решение:

Алиасы прописываются в глобальном конфиге Git. Вот самые полезные сокращения, которыми пользуются профи:

# Настройка через терминал:
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 lg'
git config --global alias.lg "log --graph --oneline --all --decorate"

# Чтобы быстро отменить последний коммит, но оставить код (uncommit)
git config --global alias.uncommit "reset --soft HEAD~1"

Почему это маст-хэв?
— Скорость: git st вместо git status — это доли секунды, которые за день складываются в минуты продуктивности.
— Кастомизация: ты настраиваешь инструмент под свои привычки.
— Меньше опечаток: короткую команду сложнее написать с ошибкой.

Как проверить свои алиасы?
Все твои настройки хранятся в файле ~/.gitconfig. Ты можешь открыть его любым редактором и отредактировать секцию [alias] вручную.

🔥 — если твой конфиг уже забит алиасами
🤝 — если по старинке пишешь команды целиком

➡️ GitHub Ready | #урок

📋 Как изменить сообщение последнего коммита? (Git Commit --amend)

Ошибки в описании — классика: опечатался, забыл указать номер задачи или просто понял, что «Fix» — это не самое информативное сообщение в мире. Если ты еще не запушил этот коммит в общий репозиторий, всё можно исправить за пару секунд.

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

Решение:

Используем флаг --amend. Эта команда берет текущую стадию (staging area) и «склеивает» её с последним коммитом, позволяя заодно переписать сообщение.

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

# Если забыл добавить файл:
git add forgotten_file.js
git commit --amend --no-edit
# Флаг --no-edit оставит прежнее сообщение, просто добавив файл

Почему это важно?
— Чистота истории: в логе не будет лишних правок типа «исправил опечатку в коммите».
— Атомарность: изменения, которые логически принадлежат одной задаче, остаются в одном коммите.
— Профессионализм: твой Pull Request выглядит аккуратно и легко читается.

Важно: Никогда не делай --amend для коммитов, которые уже улетели в общую ветку (push). Это меняет хэш коммита, и у твоих коллег возникнут конфликты при попытке обновиться.

🔥 — если постоянно правишь свои сообщения
🤝 — если оставляешь опечатки как часть «авторского стиля»

➡️ GitHub Ready | #урок

🛠 Как отменить последние изменения? (Git Reset)

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

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

Решение:

Команда reset перемещает указатель ветки на нужный коммит. Есть три основных режима:

# 1. SOFT — отменяет коммит, но оставляет все правки в индексе (готовы к коммиту).
# Идеально, если нужно просто переписать сообщение или объединить файлы.
git reset --soft HEAD~1

# 2. MIXED (по умолчанию) — отменяет коммит и убирает файлы из индекса, 
# но оставляет их в рабочей директории.
git reset HEAD~1

# 3. HARD — удаляет всё подчистую. Коммит исчезает, а файлы возвращаются 
# к состоянию "как было до этого коммита".
# Осторожно: несохраненные правки удалятся навсегда!
git reset --hard HEAD~1

Почему это полезно?
— Исправление ошибок: можно быстро «откатиться», если тесты упали после последнего коммита.
— Чистка индекса: если случайно добавил в git add лишние папки (например, node_modules).
— Гибкость: ты сам решаешь, насколько глубоко нужно «стереть» историю.

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

🔥 — если часто юзаешь --soft, чтобы переделать коммит
🤝 — если используешь только --hard, потому что «гулять так гулять»

➡️ GitHub Ready | #урок

♻️ Как вернуть «удаленный» коммит? (Git Reflog)

Ты сделал git reset --hard и внезапно осознал, что удалил не тот коммит? Кажется, что код потерян навсегда, а часы работы улетели в пустоту. Но в Git почти ничего не исчезает бесследно, пока жива папка .git.

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

Решение:

На помощь приходит reflog (reference log) — это журнал всех перемещений указателя HEAD. Он записывает каждый ваш шаг, даже если вы прыгаете по истории или удаляете ветки.

# 1. Смотрим историю всех действий
git reflog

# Ты увидишь список вроде:
# ab12cd3 HEAD@{0}: reset: moving to HEAD~1
# ef45gh6 HEAD@{1}: commit: Добавил важную фичу  <-- ВОТ ОН!

# 2. Возвращаемся в то состояние, где всё было хорошо
git reset --hard ef45gh6

# Или просто создаем новую ветку из этого состояния, чтобы ничего не сломать
git branch recovery-branch ef45gh6

Почему это спасает жизни?
— Страховка: ты можешь смело экспериментировать с rebase и reset, зная, что всегда есть «черный ящик» с записями.
— Спокойствие: даже если ты удалил ветку целиком, её коммиты всё еще лежат в логе еще как минимум 30 дней (пока не придет Garbage Collector).
— Точность: reflog показывает не просто историю проекта, а твою личную историю действий в этом репозитории.

Важно: reflog хранится только локально. Если ты удалил что-то и переустановил систему или удалил папку с проектом, восстановить данные через него не получится.

🔥 — если reflog уже спасал твою карьеру
🤝 — если после reset --hard просто уходишь в депрессию

➡️ GitHub Ready | #урок

🧹 Как очистить репозиторий от лишнего мусора? (Git Clean)

После долгой работы в проекте скапливаются не только коммиты, но и «хвосты»: временные логи, созданные скриптами папки, файлы конфигураций, которые ты забыл добавить в .gitignore, или просто артефакты сборки. Команда git status показывает их как untracked files, и они мозолят глаза.

Задача:
— Быстро удалить все файлы и папки, которые не отслеживаются Git.
— Привести рабочую директорию в идеально чистое состояние.

Решение:

Используем команду git clean. Она работает жестко, поэтому у неё есть «предохранитель» — по умолчанию она ничего не удалит без специального флага.

# 1. Сначала всегда делай "прогон" (dry run)
# Git просто покажет список файлов, которые будут удалены
git clean -n

# 2. Удалить все неотслеживаемые файлы
git clean -f

# 3. Удалить и файлы, и целые папки (directory)
git clean -fd

# 4. Удалить даже те файлы, что прописаны в .gitignore 
# (полезно, если нужно полностью пересобрать проект с нуля)
git clean -fdx

Почему это полезно?
— Порядок: git status снова становится коротким и понятным.
— Устранение багов: иногда странное поведение программы лечится просто удалением старых конфигов или кэша, которые застряли в папках.
— Подготовка: перед тем как заархивировать проект или передать его коллеге, стоит вычистить всё лишнее.

Важно: Будь предельно осторожен с флагом -x. Он удалит и node_modules, и .env файлы с ключами доступа. Всегда проверяй список через -n перед финальным запуском.

🔥 — если любишь, когда в status идеальная чистота
🤝 — если годами хранишь temp_v2_old.txt в корне проекта

➡️ GitHub Ready | #урок

🌍 Глобальный .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 | #урок