git.txt

1️⃣ Настройка имени и почты (очень важно для коммитов)
        git config --global user.name "Твоё Имя"
        git config --global user.email "email@example.com"

Показывает имя и адрес пользователя:
         git config --global user.name
         git config --global user.email
		или список пользователей:
         git config --list

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


2️⃣ Как «выходить» из Git на чужом компьютере:
Очистить глобальные настройки Git (если нужно)
   git config --global --unset user.name
   git config --global --unset user.email

Или удалить все глобальные настройки:
    git config --global --remove-section user

Проверка пользователей:
    git config --list
или 
    git config --global user.name


3️⃣ Клонирование и работа с репозиторием
        git clone <адрес удалённого репозитория> - если мы используем SSH-key, в таком случаи мы копируем для клонирования адрес тот который под вкладкой SSH

    Перейди в папку проекта
        cd название-проекта
    
    Установи зависимости
        npm install   (npm i), также можна использозовать
        npm ci - считаеться красивой практикой
    или, если в проекте есть файл yarn.lock, используй:
        yarn install

    Создай новую ветку (ОБЯЗАТЕЛЬНО)
    Никогда не делай правки в ветке main или master. Для каждой задачи создавай отдельную ветку.

        git checkout -b feature/ITDEV-123-short-description
                - feature/ — тип задачи (может быть bugfix/ или hotfix/).
                - ITDEV-123 — номер задачи из Jira.
                - short-description — краткое пояснение (например, add-login-logic).
      ➡️Если, что мы можем переименовать верку: git branch -m <новое название ветки>
      💥Файл .env: Часто после клонирования проект не запускается, потому что нужны ключи доступа. Поищи файл .env.example, скопируй его в .env и спроси у ребят значения для переменных.
📢 Если у меня нет репозитория но есть уже готовый проект на локальном ПК:
    - git init - создаст локально новый репозиторий в текущей директории
    - git add . - добавляем изменённые файлы
    - git commit -m "комент" - делаем коммит
        Переходим в GitHub, создаём новый репозиторий и привязываем репозиторий нп локальном ПК к репозиторию на GitHub
    - git remote add origin https://github.com/ShevchenkoOl/awsTrenee.git
    ‼️если мы используем SSH-ключ тогда копируем ссылку SSH, но если у нас есть несколько аккаунтов с разными SSH-ключами:
        git remote set-url origin git@github-personal:ShevchenkoOl/aws-trenee.git  - добавляем название ключа
    - git branch -M main
    - git push -u origin main

    Напиши код. Теперь открывай проект в VS Code (code .) и делай свои задачи. Как только часть работы готова, нужно сохранить изменения локально.

    Сделай коммит
    Сначала «подготовь» файлы, а потом «зафиксируй» их:
        git add . 
    или вместо точки пишем конкретное имя файла или папки которую мы ходит добавить в staging area
        git add fileName.js

        git commit -m "ITDEV-123: реализована валидация формы входа"

    Отправь ветку на GitHub

        git push -u origin feature/ITDEV-123-short-description

    Флаг -u нужен только в первый раз для новой ветки.

4️⃣ Создай Pull Request (PR)
Теперь иди в интерфейс GitHub. Он сам предложит тебе: "You recently pushed a branch... Compare & pull request" -> Нажми на эту кнопку -> Опиши, что ты сделал.-> Назначь коллег (например, Ондржея) в качестве Reviewers.

⚠️Важные советы для начала работы:
        - Всегда проверяй, где ты: Перед созданием ветки или коммитом пиши git status. Это твоя главная команда, чтобы не запутаться.
        - Синхронизируйся: Перед тем как создавать новую ветку утром, обнови основную ветку, чтобы у тебя был актуальный код коллег:
        1. git branch - проверяем в какой ветке находимся (добавляя влаг -D <имя ветки> - удаляем ветку)
        2. git checkout main - переключаемся со своей ветки на главную
        3. git pull origin main - подтягиваем последнии изменения перед тем как мы начнём работать
        4. git checkout feature/ITDEV-123-short-description - назад возвращаемся на свою ветку и тогда совмещаем ее с главной
                git merge main — (Важный шаг!) Ты вливаешь свежий код из main в свою рабочую ветку.
        или создаешь новую - git checkout -b feature/NEW-TICKET ( -b флаг который создаёт новую ветку)
        ➡️ Если мы не правильно назвали ветку или просто ее нужно переименовать и ОНА ЕЩЁ НЕ УДЕТЕЛА НА GitHub:
        1. переходим в ту ветку которую нужно переименовать;
        2. git branch -m <новое название ветки>

        ➡️ Если мы уже успели отправить старую ветку на сервер:
        Тогда нужно сделать три шага: переименовать локально, отправить новую на сервер и удалить старую с сервера (чтобы не путать коллег).
        1. Переименовываем ветку у тебя на компьютере
        git branch -m <новое название ветки>

        2. Отправляем новую (переименованную) ветку на сервер и связываем её
        git push origin -u <новое название ветки>

        3. Удаляем старое название ветки с сервера
        git push origin --delete <старое название ветки>

📢 Если мне нужно что-то доработать в коде это называеться Code Review (ревью кода). В этом случае алгоритм будет немного другим, потому что новую ветку (и новый Pull Request) создавать не нужно — просто продолжаем работу в той же самой:
    1️⃣ git checkout имя ветки  - переключаемся без флага `-b` (потому что ветка уже существует, мы её не создаем, а просто в неё заходим). Внимание: если забыл точное длинное название, просто напиши в терминале `git branch`, и он покажет список всех твоих локальных веток. Выйти из этого списка можно кнопкой `q` на клавиатуре
    2️⃣ git pull - Подтяни изменения (на всякий случай)
    3️⃣ Вноси исправления в код, работаем с кодом
    4️⃣ По окончанию работи с кодом, делаем стандартную процедуру сохранения:
        git add .
        git commit -m "fix: address code review comments", если в проекте использовано husky, в конце уоммита можна добавить фоаг --no -verify
        git push - Здесь уже не нужно писать длинное git push -u origin ..., так как ветка уже навсегда привязана к серверу. Достаточно просто git push.
    5️⃣ Магия GitHub, не нужно создавать новый Pull Request! Как только ты сделаешь git push, твой новый код автоматически (за секунду) подгрузится в тот самый PR, который ты уже создал раньше. Роботы-проверяльщики (GitHub Actions) тоже запустятся заново сами.

      
Ещё пару интересных команд:
    1️⃣   git restore .                  - отменяет все изменеие
    2️⃣   git restore --staged <soubor>  - отменяет файл/папку из stange area
    3️⃣   git commit --no-verify -m "твой текст" - Если ошибка была вызвана инструментом Husky (это так называемый pre-commit hook — скрипт, который автоматически срабатывает до того, как создастся коммит), он проверяет красивое рфрпмоение кода, отступов и т.д. флаг --no-verify игнорирует жту проверку
    4️⃣   git commit --amend - Если ты сделал коммит, но забыл добавить один файл или сделал опечатку в сообщении. Как работает: Добавляет новые изменения в предыдущий коммит, не создавая новый. (Сначала делаешь git add ., потом git commit --amend). Можно добавить команду --no-edit скажет гиту: "Добавь файл в последний коммит, но оставь старое сообщение (про refactor config)".
    5️⃣   git push --force (или -f) - Перезаписывает историю на сервере (на GitHub). Как работает: Часто используется после --amend. Осторожно: никогда не используй в ветке main/master, только в своих рабочих ветках! Возможно терминал может выдать предупреждение тогда нужно воспользоваться командой: git push --force-with-lease --set-upstream origin <имя ветки>
    6️⃣   git add -p - Добавляет изменения в коммит не целиком, а по кусочкам. Как работает: Git будет показывать тебе каждый измененный блок кода и спрашивать: y/n (добавлять или нет?). Удобно, когда в одном файле ты решал задачу, а в другом просто тестировал и хочешь закоммитить только решение.
    7️⃣   git stash  - берет все твои измененные файлы и временно прячет их в скрытый ящик, оставляя рабочую папку абсолютно чистой.
         git stash pop - Достаем изменения из временного ящика.
    8️⃣   git reset HEAD = возвращает репозиторий в более раннее состояние на текущий коммит.
                HEAD~1 — означает “на один коммит назад от текущего HEAD” или предидущий
                HEAD~2 = два коммита назад и т.д.
         git reset --hard 8f83069 - или указываем номер коммита
    9️⃣   git restore .  - что не добавили в staging area удали всё остальное
    1️⃣0️⃣ git push --force - Если локальная история отличается от удалённой (например, ты сделал git reset HEAD~1 или git rebase), но нам всё равно нужно запугить тогда этот флаг нам помагает очистить (перезаписать) предидкщий коммит который мы проигнарировали
    1️⃣1️⃣ git fetch --all  - «Разведка» по всем фронтам. Git связывается со всеми удаленными репозиториями (origin и другими, если они есть) и скачивает информацию о новых ветках и коммитах. Она ничего не меняет в вашем коде, только обновляет «карту» того, что произошло в облаке, пока вы не смотрели.
          git fetch --prune или просто -p - запускаеться в главной ветке проекта и показывает удалённые ветки этого проекта,  синхронизирует ваш локальный репозиторий с удаленным (например, с GitHub). Она скачивает новые коммиты и информацию об изменениях, а затем удаляет локальные ссылки на удаленные ветки
          git fetch origin pull/715/head:review-715 - скачивает содержимое конкретного Pull Request №715 и и создаёт из него локальную ветку review-715
    1️⃣2️⃣ git rebase — это «переезд» твоих изменений на новый фундамент. Он берет все твои коммиты, временно откладывает их в сторону, обновляет твою ветку до самого свежего состояния main, а затем по одному приклеивает твои коммиты обратно в самый конец очереди. 
        В чем разница с Merge:
            ➡️Merge: Создает один большой коммит-склейку. История выглядит как дерево с переплетающимися ветками. Грубое связывание двух веток общим узлом Это может выглядеть запутанно. Сначала стягиваем последнии изменеия:
                git checkout main -> git pull -> git checkout <наша робочая ветка> -> git merge main -> git push
            - Если при marge возникли конфликты и мы не хотим их решать, мы можем остановить merge:  git merge --abort
            ➡️Rebase: Переписывает историю так, будто ты только что создал свою ветку от самого свежего кода.То есть аккуратная "пересадка" твоих изменений поверх свежего мастера по одному коммиту, чтобы история оставалась идеально прямой линией. В таком случаи История коммитов становится идеально ровной. Короткая шпаргалка по rebase:
                        1. Обновляем главную ветку (master)
                            git checkout master
                            git pull
                        2. Возвращаемся в свою рабочую ветку. Переключаемся на ту ветку, над которой работаешь.
                            git checkout nazvanie-tvoey-vetki
                        3. Запускаем Rebase
                            git rebase master
                        4. Решаем конфликты (если Git остановился). Если в терминале появилось слово CONFLICT, процесс встал на паузу. Открываем редактор (VS Code), находим проблемные файлы и решаем конфликты (принимаем нужные изменения). Например: $ git rebase master CONFLICT (modify/delete): app/shop/package-lock.json deleted in HEAD and modified in f8929aa (feat(shop): add ZahranicniPage and fix checkout routing)........ В ветке master удалён app/shop/package-lock.json - поэтому мы его тоже удалим у нас:
                            git rm app/shop/package-lock.json
                        Когда файлы исправлены, добавляем их в индекс:
                            git add .
                        5. Говорим Git продолжать (⚠️ Важно: git commit здесь делать не нужно!):
                            git rebase --continue (Повторяем этот шаг, если конфликтов несколько, пока не увидим надпись Successfully rebased).
                        6. Отправляем на сервер (Force Push). Так как история коммитов изменилась, сервер не примет обычный push (и предложит сделать pull — игнорируем это!). Отправляем изменения принудительно:
                            git push origin nazvanie-tvoey-vetki --force (Или более безопасный вариант: --force-with-lease).
    1️⃣3️⃣ git remote set-url origin git@github.com:<адрес репозитория с SSH-ключом> - переключит «адрес» (remote url) репозитория с HTTPS на SSH
            ➡️ git remote -v - проверяем или переключила
    1️⃣4️⃣ git log --oneline -n 5 - показывает пять (или колтчество можно поменять) последних коммитов
    1️⃣5️⃣ git log -S "<ключевое слово поиска>" -p -- <в каком файле мы ищем> - команда помагает найти во всех коммитах по ключевому слову и в конкретном месте например: git log -S "email" -p -- server/model/services/users/UserQueryBuilder.ts - если нам нужно во всём проекте то мы не указываем места, то есть код пигем до --. Флаг -p сразу покажет тебе, какие именно строки были удалены красным цветом. Также можна использовать поиск по текущему состоянию кода:
            git grep "ключевые слова или фразы поиска", можна добавть флаг -n для указание строки в файле: git grep -n "email" - работает как классический поиск в VScode Ctrl + Shift + f
    1️⃣6️⃣ git log --graph --oneline --decorate -n 15 - показывает дерево последних действий с ветками
    1️⃣7️⃣ git log <ветка1>..<ветка2> - показывает расхождение ветотки 1 с веткой 2 например git log develop..main
    1️⃣8️⃣ git reflog - логи последних действий с ветками

💥 Ветка nightly - В крупных проектах это «интеграционная» ветка. Обычно именно в неё сливаются все новые фичи для ежедневного внутреннего тестирования (отсюда и название — ночная сборка).
для проведение качественного и грамотного деплоя лучше всего нашу робочую ветку слиять с веткой nightly:
    после коммита и push нашей робочей ветки
    git checkout nightly
    git pull origin nightly   # на всякий случай заберем чужое
    git merge HPX-1295-edp-ma-statickou-ip-adresu
    git push origin nightly


🔥 Команды для работы с npm (node packege manager) 🔥
1️⃣ Установка зависимостей проекта: npm ci vs npm i:
      - Для свежесклонированного проекта однозначно лучше использовать npm ci (Clean Install). Почему npm ci: Он строго ориентируется на package-lock.json и не пытается разрешать версии зависимостей заново. Это гарантирует, что у тебя локально поднимется ровно то же самое окружение, которое сейчас работает на проде (и собирается в CI/CD). Никаких сюрпризов из-за минорных обновлений библиотек.
      - Когда использовать npm i: Оставь эту команду для моментов, когда тебе нужно добавить новый пакет или целенаправленно обновить текущий (чтобы обновить package-lock.json).

2️⃣ При инсталяции проекта, может возникнуть ошибка связана с немовместимостю аерсий node
например:
        npm warn EBADENGINE   required: { node: '20.17.0', npm: '10.8.3' },
        npm warn EBADENGINE   current: { node: 'v22.14.0', npm: '10.8.1' }
    для решение этой проблемы достаточно поменять версию node:
        nvm install 20.17.0   - указываем ту версиюкоторую требует проект
        nvm use 20.17.0       - начинаем принудительно использовать
Если при роботе Linux напигет что nvm не найден, устанавливаем его:
        curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
    Активируем NVM
        source ~/.bashrc

npm run lint запускает линтер — инструмент, который проверяет код на ошибки и стиль.
                                Обычно используется линтер вроде ESLint. Он проверяет:
                                    - синтаксические ошибки
                                    - потенциальные баги
                                    - несоблюдение правил код-стайла
                                    - неиспользуемые переменные
                                    - неправильные импорты и т.п.

📢 Как правильно писать коммиты
Формат коммита                   <тип>(контекст)!: краткое описание
                                 [тело — при необходимости]
                                 [сноски — при необходимости]
🔹 Основные типы
        feat	Новая функциональность
        fix	    Исправление бага
        BREAKING CHANGE или !	Ломающие изменения
🔹 Дополнительные типы (рекомендуемые)
        docs	Документация
        style	Форматирование (без изменения логики)
        refactor	Рефакторинг без изменения поведения
        perf	Улучшение производительности
        test	Тесты
        build	Сборка, зависимости
        ci	    CI/CD
        chore	Прочее (конфиги, мелочи)
        revert	Откат коммита

Как выбирать тип (быстрое решение)
Спроси себя:
            Я добавил функциональность? → feat
            Я исправил баг? → fix
            Я сломал обратную совместимость? → ! или BREAKING CHANGE
            Я просто улучшил код без изменения логики? → refactor
            Я ничего не меняю в логике? → style
            Я добавил тесты? → test

📢 Как обединить все комммиты в один, в том случаи когда code rewiev делаеться по частям:
    1. у нас уже есть один отправленный (запушенный) на GitHub коммит (например, feat: add dynamo db hash), и ты получаешь к нему комментарии на ревью:
        - Вносишь правки и добавляешь их. Исправил баг, удалил логгер. Пишешь как обычно:
            git add .

        - Делаешь fixup-коммит. Здесь тебе нужен хэш (первые 7 букв/цифр) того самого оригинального коммита, который ты хочешь "починить".
            git commit --fixup <хэш_оригинального_коммита>, (Git создаст коммит с именем fixup! feat: add dynamo db hash). Хеш коммита можна полусить вот жтой командой:
            git log --oneline -n 5

        - Повторяешь по необходимости. Нашел еще ошибку? Снова git add . и снова git commit --fixup <хэш>. Пушить пока не нужно, копишь их локально.

        - Запускаешь магию склеивания (Rebase). Когда ты всё исправил и готов обновить Pull Request, ты даешь команду Git'у склеить всё это в один коммит. Обычно ребейз делают на ветку main:
            git rebase -i --autosquash main - Откроется текстовый редактор, где Git уже сам расставит все твои fixup-коммиты под нужным оригинальным коммитом со словом fixup. Тебе нужно просто сохранить и закрыть файл. Git всё сплющит!

        - Отправляешь на GitHub (ОЧЕНЬ ВАЖНЫЙ МОМЕНТ ⚠️). Так как ты сделал Rebase (то есть переписал историю коммитов), обычный git push выдаст ошибку! GitHub скажет: "Эй, у меня тут другая история, я не приму это". Поэтому пушить нужно с флагом принудительной записи (force):
            git push --force-lease

👉 GitHub Deploy:
 - Actions -> deploy_nightly -> Run workflow -> Branch:выбираем нашу ветку -> Run workflow

 📢 Несколько полезных команд связаных с npm:
 1️⃣ npm install --legacy-peer-deps - используется для принудительной установки пакетов, игнорируя конфликты в версиях одноранговых зависимостей (peerDependencies). Она заставляет npm использовать алгоритм разрешения зависимостей из 6-й версии (legacy), что позволяет установить пакеты, даже если они не полностью совместимы с текущей версией вашего проекта.


 👉 Trunk-Based Development основные правила и алгоритм:
        Шаг 1: Начинаем задачу (всегда от main). Перед тем как писать код, тебе нужно переключиться на главную ветку и забрать самые свежие изменения, которые туда успели замержить коллеги:

                git checkout main
                git pull origin main

        Шаг 2: Создаем ветку. Создаешь свою обычную рабочую ветку, но теперь она отпочковывается напрямую от актуального main:
                
                git checkout -b fix/HPX-XXXX-short-description

        Шаг 3: Пишем код и пушим. Сделал задачу, проверил, закоммитил и отправил на GitHub. Код в main всегда должен быть рабочим. Раз промежуточных веток больше нет, твой PR пойдет прямиком в продакшен (после тестов). Поэтому перед отправкой убедись, что проект хотя бы собирается локально:

                npm run build
                git add .
                git commit -m "fix: something important"
                git push origin fix/HPX-XXXX-short-description

        Шаг 4: Создаем Пулл-Реквест на GitHub (Важный момент!). Когда ты зайдешь в интерфейс GitHub, чтобы нажать кнопку Create pull request, обрати внимание на поле base branch (куда ты вливаешь код).
            - Как было раньше: Ты мог выбирать base: nightly или base: develop.
            - Как нужно делать теперь (Trunk-Based): В поле base всегда должен стоять main.
                base: main  ←  compare: fix/HPX-XXXX...


👉 Некоторые полезные команды:
    - игнорируем линтер на конкретной строчки и с конкретным замечанием: // eslint-disable-next-line no-console