Vue Front-end Инженер

Vue Front-end Инженер

Роадмап навыков для прокачки

Базовые операции Git

Software Development Processes → Система контроля версий (Git) → Основное

Основная идея

Базовые операции Git — это набор команд для ежедневной работы с системой контроля версий: инициализация репозитория, отслеживание изменений, создание коммитов и синхронизация с удалённым репозиторием.

Ключевые команды

  • git init — инициализация нового репозитория
  • git clone — клонирование существующего репозитория
  • git status — просмотр текущего состояния файлов
  • git add — добавление файлов в staging area
  • git commit — сохранение изменений в истории
  • git push — отправка коммитов на удалённый сервер
  • git pull — получение и слияние изменений с сервера
  • git log — просмотр истории коммитов

Три состояния файлов в Git

  • Modified — файл изменён, но не добавлен в staging
  • Staged — файл добавлен в staging и готов к коммиту
  • Committed — изменения сохранены в локальной истории

Типичный рабочий процесс

  1. Внести изменения в файлы
  2. git add . — добавить в staging
  3. git commit -m "описание" — зафиксировать изменения
  4. git push — отправить на сервер

Частые ошибки на собеседованиях

  • Путают git pull и git fetch (pull = fetch + merge)
  • Не понимают разницу между staging area и committed
  • Забывают про .gitignore для исключения файлов
  • Не знают как отменить изменения (git checkout, git reset, git revert)

Введение и проблематика

Git — это распределённая система контроля версий, которая позволяет отслеживать изменения в коде, работать над проектом совместно с другими разработчиками и возвращаться к предыдущим версиям при необходимости.

Git создан Линусом Торвальдсом в 2005 году для разработки ядра Linux. Сегодня это стандарт индустрии для контроля версий.

Зачем нужен Git?

  • История изменений — можно посмотреть, кто, когда и что изменил
  • Откат изменений — вернуться к рабочей версии при ошибке
  • Параллельная работа — несколько разработчиков работают над одним проектом
  • Резервное копирование — код хранится на сервере и у каждого разработчика
  • Code Review — возможность просмотреть изменения перед слиянием

Базовая теория

Три области Git

graph LR A[Working Directory] -->|git add| B[Staging Area] B -->|git commit| C[Repository] C -->|git checkout| A
ОбластьОписание
Working DirectoryРабочая папка с файлами проекта
Staging Area (Index)Промежуточная область для подготовки коммита
RepositoryЛокальное хранилище с историей коммитов

Состояния файлов

stateDiagram-v2 [*] --> Untracked: Новый файл Untracked --> Staged: git add Staged --> Committed: git commit Committed --> Modified: Изменение файла Modified --> Staged: git add Staged --> Modified: git restore --staged

Практические примеры

Инициализация и первый коммит

Шаг 1: Создание репозитория

bash
# Создать новый репозиторий
git init
 
# Или клонировать существующий
git clone https://github.com/user/repo.git

Шаг 2: Настройка пользователя

bash
git config --global user.name "Ваше Имя"
git config --global user.email "email@example.com"

Шаг 3: Добавление файлов

bash
# Добавить конкретный файл
git add index.html
 
# Добавить все файлы
git add .
 
# Добавить все файлы определённого типа
git add *.js

Шаг 4: Создание коммита

bash
git commit -m "Initial commit: add project structure"

Шаг 5: Отправка на сервер

bash
# Связать с удалённым репозиторием
git remote add origin https://github.com/user/repo.git
 
# Отправить изменения
git push -u origin main

Основные команды на каждый день

bash
# Текущее состояние файлов
git status
 
# Краткий статус
git status -s
 
# История коммитов
git log
 
# Компактная история
git log --oneline
 
# История с графом веток
git log --oneline --graph --all
 
# Просмотр изменений в файлах
git diff
 
# Изменения в staging area
git diff --staged

Файл .gitignore

⚠️

Важно настроить .gitignore в начале проекта, чтобы не коммитить лишние файлы (зависимости, конфигурации IDE, секреты).

bash
# Пример .gitignore для Node.js проекта
 
# Зависимости
node_modules/
 
# Переменные окружения
.env
.env.local
 
# Логи
logs/
*.log
 
# Сборка
dist/
build/
 
# IDE
.idea/
.vscode/
*.swp
 
# OS файлы
.DS_Store
Thumbs.db

Пограничные кейсы

Разница между git pull и git fetch

graph TD A[git fetch] --> B[Скачивает изменения] B --> C[Не сливает с локальной веткой] D[git pull] --> E[Скачивает изменения] E --> F[Автоматически сливает]

git pull = git fetch + git merge. Используйте fetch, когда хотите сначала посмотреть изменения, и pull для быстрого обновления.

Отмена изменений

СитуацияКоманда
Отменить изменения в файлеgit restore file.js
Убрать файл из staginggit restore --staged file.js
Отменить последний коммит (сохранив изменения)git reset --soft HEAD~1
Отменить последний коммит (удалив изменения)git reset --hard HEAD~1
Создать коммит отменыgit revert HEAD
🚫

git reset --hard удаляет изменения безвозвратно! Используйте с осторожностью.

Плюсы и минусы Git

ПреимуществаНедостатки
Распределённость — каждый имеет полную копиюСложная кривая обучения
Быстрая работа — большинство операций локальныеМного команд с похожими названиями
Надёжность — криптографические хешиМожет быть сложен для не-программистов
Гибкость — разные workflowMerge-конфликты требуют ручного разрешения
Бесплатный и open-sourceБольшие бинарные файлы хранятся неэффективно

Вопросы интервьюера

Q: Чем отличается git pull от git fetch?

fetch только скачивает изменения с сервера, pull скачивает и сразу сливает с текущей веткой

Q: Что такое staging area?

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

Q: Как отменить последний коммит?

git reset --soft HEAD~1 (сохранит изменения) или git reset --hard HEAD~1 (удалит изменения). Для публичной истории — git revert

Q: Что делает git clone?

Создаёт полную копию удалённого репозитория со всей историей коммитов

Q: Как посмотреть изменения перед коммитом?

git diff для unstaged изменений, git diff --staged для staged

Источники