WALUDO Инструменты
DOCS.01 WALUDO DOCS

Памятка по Git

Справочник распространённых команд Git: настройки, ветки, коммиты, слияние, отмена изменений, удалённые репозитории и Conventional Commits с редактируемыми примерами.

Быстрая навигация

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

Большинство команд ниже собрано на it-tools.tech и дополнено практикой повседневной разработки.

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

Настройка

Задайте глобальные имя пользователя и адрес электронной почты:

bash 
git config --global user.name "WaLudo"
git config --global user.email "[email protected]"

Начало проекта

Инициализируйте новый Git-репозиторий:

bash 
git init

Клонируйте существующий Git-репозиторий:

bash 
git clone https://github.com/WaLudo/waludo-tools.git

Коммиты

Зафиксируйте все отслеживаемые изменения:

bash 
git commit -am "feat: add two cups of coffee"

Зафиксируйте все изменения:

bash 
git add .
git commit -m "feat: add five cups of coffee"

Добавьте новые изменения к последнему коммиту:

bash 
git commit --amend --no-edit

Что-то пошло не так

Измените сообщение последнего коммита:

bash 
git commit --amend

Отмените последний коммит, сохранив изменения:

bash 
git reset HEAD~1

Отмените последние N коммитов, сохранив изменения:

bash 
git reset HEAD~N

Отмените последний коммит и удалите все изменения:

bash 
git reset HEAD~1 --hard

Верните локальную ветку к состоянию удалённого репозитория:

bash 
git fetch origin
bash 
git reset --hard origin/branch-name

Прочее

Переименуйте локальную ветку master в main:

bash 
git branch -m master main

Соглашение о коммитах

Обратитесь к спецификации Conventional Commits v1.0.0.

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

git commit -m "feat(scope): description"

Краткий справочник типов

ТипОписание
fixИсправляет ошибку
featДобавляет новую функцию
buildИзменяет систему сборки (зависимости, внешние интерфейсы, версию Node и т. п.)
choreИзменяет не бизнес-логику (процесс сборки, настройки инструментов и т. п.)
ciИзменяет конфигурацию непрерывной интеграции (CI/CD)
docsИзменяет документацию (README, документацию API и т. п.)
styleМеняет стиль кода без изменения логики
refactorПерестраивает код без изменения поведения
perfУлучшает производительность
testИзменяет тестовые случаи

Область Scope

После типа можно указать область в скобках, чтобы добавить контекст:

feat(parser): adds ability to parse arrays

Критические изменения

Восклицательный знак обозначает критическое изменение и может использоваться с любым типом:

feat(api)!: send an email to the customer when a product is shipped

Того же результата можно добиться, указав BREAKING CHANGE в футере.

Многострочное тело и футер

Пример коммита с многострочными телом и футером:

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Полная спецификация

Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL следует толковать согласно RFC 2119.

  • Каждый коммит MUST начинаться с типа, затем могут идти OPTIONAL область, OPTIONAL восклицательный знак и REQUIRED двоеточие с пробелом
  • Новая функция MUST использовать тип feat
  • Исправление ошибки MUST использовать тип fix
  • Область MAY следовать за типом; это MUST быть существительное, описывающее часть кодовой базы в скобках, например fix(parser):
  • Описание MUST сразу следовать за двоеточием и пробелом после префикса типа и области
  • После краткого описания MAY идти расширенное тело, которое MUST начинаться после пустой строки
  • После ещё одной пустой строки MAY идти один или несколько футеров; каждый футер MUST содержать токен и разделитель
  • Токен футера MUST использовать дефис вместо пробелов, например Acked-by; исключение — BREAKING CHANGE
  • Критическое изменение MUST отмечаться ! в префиксе или футером BREAKING CHANGE: описание
  • Если используется !, BREAKING CHANGE: MAY быть опущено в футере, а описание SHOULD объяснять изменение
  • Помимо feat и fix MAY использоваться другие типы, например docs: updated ref docs.
  • Инструменты спецификации MUST разбирать информационные элементы без учёта регистра, но BREAKING CHANGE MUST оставаться в верхнем регистре
  • BREAKING-CHANGE MUST быть синонимом BREAKING CHANGE в качестве токена футера