Терминология Git / Github

Repository / Репозиторий – директория, где хранятся файлы проекта, может быть локальным и удаленным.
Branch / Ветка – параллельная версия репозитория, которая хранит примерное теже файлы, что и оригинальная ветвь, но при этом не оказывает на неё влияние.
Fork / Форк – новый репозиторий, в котором есть код другого репозитория.
Merge / Мердж – сохранение изменений из одной ветки в другую.
Pull request – запрос на сохранение изменений из одной ветки в другую.Или из форка в upstream репозиторий.
Fast-forward merge – быстрое сохранение изменений, происходит как-бы продление head ветки на коммиты указанной ветки. Происходит без нового коммита.
Non-fast-forward – сохранение изменений, происходит полное слияние с созданием коммита соединения. Происходит с созданием нового коммита.
Squash Commits – засовываем одни изменения (например технических коммитов) в другие.
Stash – стек временного хранения файлов.
Rebase – перенос коммитов из одной ветки в другую с удалением их старых экзмепляров.
Issues – обсуждение проблем между пользователями прямо в коде (github/gitlab platforms)

Конфигурация пользователя

git config --global user.name "Your Name"
git config --global user.email "your@email.com"
# Проверка
git config --list

Инициализация репозитория

Два варианта: через CLI или через веб-интерфейс.

Через CLI:

# 1. Создай локальный репозиторий
git init
# 2. Добавь файлы
git add .
# 3. Сделай первый коммит
git commit -m "Initial commit"
# 4. Создай репозиторий на GitHub
gh repo create <имя-репо> --public --source=. --remote=upstream
# 5. Отправь код
git push -u upstream main

Через веб-интерфейс (дописать)

Процесс создания коммита и пуша на ветку

git add . - добавить все файлы в промежуточную область
git commit -m "сообщение" - сделать коммит (локально)
git push origin main - отправить коммит на сервер (удаленно)

Просмотр логов

git log - посмотреть hash код
git log —oneline - вывод в одну строку
git status - посмотреть статус файлов репозитория
git reflog - посмотреть последние операции | просмотр операций

Получение изменений с удаленного сервера

git fetch - получение изменений с удаленного сервера (без изменения внесенных локальных изменений)
git pull - скачивает изменения и сразу пытается влить их в текущую ветку. Если есть конфликты с локальными изменениями, процесс остановится
git pull --rebase — скачивает изменения и «накладывает» твои локальные коммиты поверх них, вместо создания merge-коммита. Это делает историю линейной и чистой.

Работа с коммитами

git commit --amend -m "Новое сообщение коммита” - изменение названия последнего коммита | переименование коммита
git commit --amend --no-edit - добавление изменений в предыдущий коммит без изменения его сообщения | внесение изменений в предыдущий коммит

Откат коммитов

git reset --hard хэш-код-стабильного-коммита - откат коммита
git reset --soft HEAD~1 - отмена ласт коммита и возврат изменений
git push —force origin ветка - отправка сообщения о удалении в удаленный репозиторий

git reset --soft HEAD^ - откат на коммит назад

Откат локальных изменений на диске

git restore <file> — отменить изменения в файле (аналог git checkout -- <file>).
git restore --staged <file> — убрать файл из индекса (unstage), но сохранить изменения в файле (аналог git reset HEAD <file>).

Поиск изменений

git blame <file> — показать, кто и когда изменял каждую строку файла.
git log -S "function_name" — найти коммиты, где добавлялась или удалялась эта строка кода.

Временное хранилище

git stash -m ’title’ - закинуть файлы в временный стек с названием
git stash list - показать список стеков
git stash show - показать файлы стека
git stash pop —index - выложить файлы назад
git stash branch - создать новую ветвь из stash

Ветки

git branch - посмотреть ветвь
git branch -a - посмотреть все ветви
git switch ветвь - перейти на другую ветвь
git checkout ветвь - перейти на другую ветвь (устаревший вариант)
git checkout -b имя_новой_ветки - создание новой ветви
git checkout -b ветвь origin/ветвь - скопировать уделенную ветвь
git checkout -b <локальная> origin/удаленная - копирование удаленной ветви на локальный диск
git branch -m название_ветки - переименование ветки

Удаление веток

git branch -d ветвь - удаление локальной ветки
git push origin --delete ветвь - удаление удаленной ветки

Отношение локальной и удаленной ветвей

git branch -vv - просмотр связей между локальной веткой и удаленными
git branch --set-upstream-to=origin/удаленная локальная - установка удаленной ветки для локальной

Перенос веток из одного репозитория в другой

git remote add source <url_исходного_репозитория> - добавляем репозиторий в качестве удаленного
git fetch source - получаем ветки удаленного репозитория
git checkout -b <имя_ветки> source/<имя_ветки> - переносим на локальный диск ветку
git push origin <имя_ветки> - пушим её без коммита
git remote remove source - удаляем удаленный источник

Слияние веток

git merge ветвь - перенос коммитов из ветви в head ветвь
git revert хэш-код-merge - отмена определенного merge

Перенос коммитов из одной ветки в другую

git cherry-pick хеш-коммита хеш-коммита - перенос коммитов из одной ветки в другую (в HEAD)

Пересмотр коммитов

git rebase -i HEAD~число - открываем rebase файл

Клонирование репозиторием

git clone URL_репозитория - клонирование репозитория
git clone --bare . your_repo.backup - клонирование только .git
git clone -b <имя_ветки> --single-branch <URL_репозитория> <локальная_папка> - клонирование отдельной ветви из одного репозитория в другой

gitignore

.gitignore файл - лежит в корневой директории репозитория и описывает файлы и директории, которые никогда не уходят в index и сооответсвенно не пушатся на сервер.

Ключи для продакшена на сервере

доступ к приватным репозиториям через ключ и именную фразу (например в VPS)

на сервере, создаем ключ для гита:

ssh-keygen -t ed25519 -C "vps-deploy" -f ~/.ssh/id_ed25519_github
cat ~/.ssh/id_ed25519_github.pub

в github переходим: Settings --> Deploy Keys
создаем ключ , указывая там его текстом (берем результат ==cat==)
проверяем результат

ls -la ~/.ssh/
git clone репозиторий

если не работает, дополняем конфиг

nano ~/.ssh/config

вставляем туда

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/название_ключа
  IdentitiesOnly yes

выдаем права:

chmod 600 ~/.ssh/config
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Доступ к ключам из поддиректорий

if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)" >/dev/null
  ssh-add ~/.ssh/id_ed25519_github 2>/dev/null
fi

Continuous Integration / Continuous Delivery

CI/CD - непрерывная интеграция и непрерывная доставка. CI - тесты и проверки в изолированной среде. CD - отправка в продакшен.

CI code:

name: CI
# выполняем только при пуше или пулл реквесте в main
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
# что выполняем
jobs:
  build:
  # билдим на последней убунту БД и проект через npm
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: portfolio_db
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 5
    env:
      DATABASE_URL: postgresql://postgres:postgres@localhost:5432/portfolio_db
      AUTH_SECRET: ci-secret-minimum-32-characters-long
      AUTH_URL: http://localhost:3000
      NEXT_PUBLIC_SITE_URL: http://localhost:3000
      ADMIN_EMAIL: admin@test.local
      ADMIN_PASSWORD: testpass
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: npm
      - name: Install
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Test
        run: npm run test
      - name: Migrate and seed
        run: |
          npx prisma migrate deploy
          npm run db:seed
      - name: Build
        run: npm run build

CD code:

создаем ключи

первым делом создаем ключ на локальной машине (для деплоя на VPS): ssh-keygen -t ed25519 -C "github-actions-cd-catshredias" -f ~/.ssh/github_actions_catshredias -N ""
вставляем ключ локальный в ключи на VPS

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "СОДЕРЖИМОЕ_файла_github_actions_catshredias.pub" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

проверяем (должно без проверки показать путь) ssh -i ~/.ssh/github_actions_catshredias deploy@IP_ВАШЕГО_VPS "cd ~/apps/catshredias-blog && pwd"
пользователь должен быть в группе docker sudo usermod -aG docker deploy && docker ps

создаем сикреты на GitHub

https://github.com/CatShredia/репозиторий/settings/secrets/actions

Secret	Пример	Откуда взять
VPS_HOST	`147.45.246.115` или `catshredia.ru`	IP/домен
VPS_USER	deploy	пользователь SSH
VPS_SSH_KEY	весь блок `-----BEGIN...END-----`	приватный ключ `github_actions_catshredias`
VPS_APP_PATH	/home/deploy/repository	абсолютный путь к репо на VPS (`pwd` в каталоге проекта)

настраиваем конфиг файл

name: CD
# запускается, когда CI на ветке main успешно прошел
on:
  workflow_run:
    workflows: [CI]
    types: [completed]
    branches: [main]
permissions:
  actions: read
  contents: read
jobs:
  deploy:
    if: >
      github.event.workflow_run.conclusion == 'success' &&
      github.event.workflow_run.head_branch == 'main' &&
      github.event.workflow_run.event == 'push'
    # выполняем подключение к серверу на ubuntu через SSH
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.2.0
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GH_REPO: ${{ github.repository }}
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          envs: GH_TOKEN,GH_REPO
          script_stop: true
          command_timeout: 25m
          script: |
            set -euo pipefail
            cd "${{ secrets.VPS_APP_PATH }}"
            # HTTPS + GITHUB_TOKEN; fetch + reset — VPS всегда = origin/main (без merge локальных коммитов)
            git -c credential.helper= fetch "https://x-access-token:${GH_TOKEN}@github.com/${GH_REPO}.git" main
            git reset --hard FETCH_HEAD
            docker compose build web migrate
            docker compose --profile tools run --rm migrate
            docker compose up -d --force-recreate web
            echo "Waiting for health..."
            ok=0
            for i in $(seq 1 30); do
              if curl -sf http://127.0.0.1:3000/api/health >/dev/null; then
                ok=1
                break
              fi
              sleep 2
            done
            if [ "$ok" -ne 1 ]; then
              echo "Health check failed"
              docker compose logs --tail=80 web
              exit 1
            fi
            curl -sf http://127.0.0.1:3000/api/health
            echo ""
            echo "Deploy OK"

Правила хорошего тона

Пиши понятные сообщения коммитов (Imperative mood: "Add feature", не "Added feature").
Не пушь в main/master напрямую (используй PR/MR).
Делай git fetch перед началом работы, чтобы знать состояние удаленного репо.
Используй git rebase для очистки истории локальной ветки перед мерджем, но никогда не делай rebase публичных веток, если над ними работают другие люди.

Шпаргалка по основным моментам «git bash» и «github»3