🗃️ GIT

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

Status: In progress

1. Основные команды

Команда	Назначение
git init	Новый локальный репозиторий
git clone <url>	Клонировать удалённый репозиторий
git status	Состояние рабочей копии и индекса
git add <file>	Добавить в индекс (staging)
git commit -m "…"	Зафиксировать индекс
git push origin main	Отправить коммиты на remote
git pull origin main	fetch + слияние в текущую ветку
git fetch	Скачать remote без слияния
git branch	Список веток
git branch <name>	Создать ветку
git checkout -b <name>	Создать ветку и переключиться
git switch -c <name>	То же (современный синтаксис)
git merge <branch>	Влить ветку в текущую
git log	История коммитов

В новых репозиториях ветка по умолчанию чаще main, не master.

2. Ветвление

Две распространённые модели. Команды выбирают одну и фиксируют в README / protected branches.

Git-Flow (кратко)

Классика с долгоживущими ветками:

Ветка	Роль
main (раньше master)	Прод: только релизы / hotfix; часто теги версий
develop	Интеграция текущей разработки
feature/*	Новая функция; создаётся от develop, merge обратно в develop
release/*	Подготовка релиза (опционально)
hotfix/*	Срочный фикс прода → merge в main и develop

main ─────●────────────●─────  (релизы)
           \          /
develop ────●────●──●────────
              \  /
         feature/login

Несколько человек на одной фиче

Ветка фичи от develop:

git checkout develop
git pull
git checkout -b feature/MW-1234

Личные ветки от фичи (если нужно параллельно):

git checkout -b dev/MW-1234/ivan feature/MW-1234
git checkout -b dev/MW-1234/masha feature/MW-1234

Готовое — merge request в feature/… или сразу в develop: кто влил раньше, того уже можно тестировать, не блокируя остальных.

GitHub Flow / trunk-based

Короче Git-Flow:

• Одна основная ветка (main)
• Короткие feature-ветки → MR → merge в main
• Деплой из main (часто сразу после зелёного CI)

Удобно, когда релизы частые и CI/CD зрелый. Git-Flow тяжелее, но явнее разделяет develop и prod.

3. Merge vs rebase

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

Merge

git checkout main
git merge feature-branch

• Создаёт merge-commit (если не fast-forward)
• История сохраняет ветвление — видно, что работали параллельно
• Безопаснее на общих ветках (main, develop)

Rebase

git checkout feature-branch
git rebase main

• Переносит коммиты фичи «поверх» main → история линейная
• Переписывает SHA коммитов — не делать rebase уже запушенных общих веток
• Удобно подчистить свою feature перед MR

	Merge	Rebase
История	С ветвлениями	Линейная
Общие ветки	Да	Осторожно / нет
Типично	Влить MR в main	Обновить свою feature от main

4. Merge conflicts

Конфликт — Git не может сам объединить правки в одном месте файла.

Как решить

1. Git укажет файлы с конфликтом (git status)

2. В файле маркеры:

   <<<<<<< HEAD
   ваш вариант
   =======
   вариант из вливаемой ветки
   >>>>>>> feature-branch
   

3. Оставить нужный код, удалить маркеры, сохранить

4. Завершить:

   git add <files>
   git commit          # после merge
   # или:
   git rebase --continue   # если был rebase
   

Пока конфликт не закрыт, push обычно не имеет смысла — сначала локально «зелёный» статус.

5. cherry-pick, tag, stash

Тонкие, но частые операции рядом с ветками.

cherry-pick

Перенести один коммит на текущую ветку:

git cherry-pick <commit-sha>

Типично: hotfix в main → тот же фикс в develop без полного merge ветки.

tag

Метка на коммите (релизы):

git tag v1.2.3
git push origin v1.2.3

Часто из main после релиза; CI может собирать артефакт по тегу.

stash

Временно убрать незакоммиченные правки:

git stash
git stash pop

Чтобы переключить ветку или быстро pull, не делая WIP-коммит.

Вопросы

В разработке..