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, только в своих рабочих ветках!
    6️⃣   git add -p - Добавляет изменения в коммит не целиком, а по кусочкам. Как работает: Git будет показывать тебе каждый измененный блок кода и спрашивать: y/n (добавлять или нет?). Удобно, когда в одном файле ты решал задачу, а в другом просто тестировал и хочешь закоммитить только решение.
    7️⃣   git stash  - берет все твои измененные файлы и временно прячет их в скрытый ящик, оставляя рабочую папку абсолютно чистой.
         git stash pop - Достаем изменения из временного ящика.
    8️⃣   git reset HEAD = возвращает репозиторий в более раннее состояние на текущий коммит.
                HEAD~1 — означает “на один коммит назад от текущего HEAD” или предидущий
                HEAD~2 = два коммита назад и т.д.
    9️⃣   git restore .  - что не добавили в staging area удали всё остальное
    1️⃣0️⃣ git push --force - Если локальная история отличается от удалённой (например, ты сделал git reset HEAD~1 или git rebase), но нам всё равно нужно запугить тогда этот флаг нам помагает очистить (перезаписать) предидкщий коммит который мы проигнарировали
    1️⃣1️⃣ git fetch --all  - «Разведка» по всем фронтам. Git связывается со всеми удаленными репозиториями (origin и другими, если они есть) и скачивает информацию о новых ветках и коммитах. Она ничего не меняет в вашем коде, только обновляет «карту» того, что произошло в облаке, пока вы не смотрели.
    1️⃣2️⃣ git rebase — это «переезд» твоих изменений на новый фундамент. Он берет все твои коммиты, временно откладывает их в сторону, обновляет твою ветку до самого свежего состояния main, а затем по одному приклеивает твои коммиты обратно в самый конец очереди. 
        В чем разница с Merge:
            ➡️Merge: Создает один большой коммит-склейку. История выглядит как дерево с переплетающимися ветками. Это может выглядеть запутанно.
            ➡️Rebase: Переписывает историю так, будто ты только что создал свою ветку от самого свежего кода. История коммитов становится идеально ровной, прямой линией.
    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 - показывает пять (или колтчество можно поменять) последних коммитов

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