Git: Merge vs Rebase vs Pull vs Fetch

1. `git fetch` vs `git pull`

git fetch: Загружает все новые данные из удалённого репозитория на локальную машину, но не изменяет рабочую ветку. Обновляются только ветки удалённого отслеживания (например, origin/main).
git pull: По сути выполняет git fetch, а затем сразу git merge полученной ветки в текущую. Обновляет локальный код напрямую.
Правило: Используйте fetch, если хотите сначала посмотреть, что сделали другие, прежде чем принимать решение о слиянии. Используйте pull, когда уверены, что хотите немедленно интегрировать изменения.

Оба используются для интеграции изменений из одной ветки в другую, но делают это по-разному.

Объединяет истории двух веток в один новый коммит (merge commit).
Плюсы: Сохраняет оригинальную историю проекта в том виде, в каком она создавалась; неразрушающий.
Минусы: Может привести к запутанной истории проекта с множеством merge-коммитов при частом использовании.

Берёт изменения из одной ветки и применяет их поверх другой. По сути переписывает историю.
Плюсы: Обеспечивает чистую, линейную историю проекта.
Минусы: Переписывание истории может быть опасным для публичных/общих веток! Никогда не делайте rebase ветки, с которой работают другие.

Fast-forward: Если в целевой ветке нет новых коммитов, Git просто перемещает указатель вперёд.
Recursive (3-way merge): Используется, когда ветки разошлись. Git находит общего предка и создаёт новый merge-коммит.

git stash: Временно «прячет» изменения, чтобы можно было переключиться на другую ветку без коммита.
git cherry-pick <commit>: Применяет конкретный коммит из одной ветки к другой.
git revert <commit>: Создаёт новый коммит, отменяющий изменения предыдущего коммита (безопаснее, чем reset).
git reset --hard <commit>: Сбрасывает текущую ветку и рабочую директорию до указанного коммита (опасно, возможна потеря данных!).