Практический сценарий использования git

Обновлено 2024-10-27 6 мин. для прочтения Computer-Science

Предлагается следующий практический сценарий использование git.
В нём мы используем стратегию git flow, скрипты для генерации общепринятых коммитов, журнала изменений.

Содержание

1 Используемые стандарты и программные продукты

Стандарт Git Flow (см. Варианты Git Workflow).
Стандарт Семантическое версионирование.
Стандарт Общепринятые коммиты.

2 Установка программного обеспечения

Для Windows используется пакетный менеджер Chocolatey (см. Пакетный менеджер для Windows. Chocolatey).
Для MacOS используется пакетный менеджер Homebrew.

2.1 Установка Node.js

На Node.js базируется программное обеспечение для семантического версионирования и общепринятых коммитов.
Для управления пакетами лучше использовать pnpm, но можно и yarn.
Gentoo
- Node.js:
```
emerge nodejs
emerge yarn
```
- pnpm ставим из оверлея guru (см. Gentoo. Дополнительные репозитории):
```
eselect repository enable guru
emerge --sync guru
emerge pnpm-bin
```

Ubuntu

apt-get install nodejs
apt-get install yarn

Fedora

dnf install nodejs
apt-get install pnpm

Windows
- Chocolatey (см. Пакетный менеджер для Windows. Chocolatey):
```
choco install nodejs
choco install yarn
choco install pnpm
```
MacOS
```
brew install node
```

2.2 Настройка Node.js

Для работы с Node.js добавим каталог с исполняемыми файлами, устанавливаемыми пакетным менеджером, в переменную PATH.

Linux
- pnpm
  - Запустите:
```
pnpm setup
```
  - Перелогиньтесь, или выполните:
```
source ~/.bashrc
```
- yarn
  - В файле ~/.bashrc добавьте к переменной PATH:
```
PATH=~/.yarn/bin:$PATH
```

2.3 Установка git-flow

Linux
- Gentoo
```
emerge dev-vcs/git-flow
```
- Ubuntu
```
apt-get install git-flow
```
- Centos
  - Первоначально нужно установить репозиторий epel (https://fedoraproject.org/wiki/EPEL):
```
yum install epel-release
```
  - Затем, собственно, установить git-flow:
```
yum install gitflow
```
- Fedora
  - Это программное обеспечение удалено из репозитория.
  - Необходимо устанавливать его вручную:
```
cd /tmp
wget --no-check-certificate -q https://raw.github.com/petervanderdoes/gitflow/develop/contrib/gitflow-installer.sh
chmod +x gitflow-installer.sh
sudo ./gitflow-installer.sh install stable
```
Windows Git-flow входит в состав пакета git.
```
choco install git
```
MacOS
```
brew install git-flow
```

2.4 Общепринятые коммиты

2.4.1 commitizen

Данная программа используется для помощи в форматировании коммитов.
- pnpm:
```
pnpm add -g commitizen
```
- yarn:
```
yarn global add commitizen
```
При этом устанавливается скрипт git-cz, который мы и будем использовать для коммитов.

2.4.2 standard-version

Данная программа автоматизирует изменение номера версии.
- pnpm:
```
pnpm add -g standard-version
```
- yarn:
```
yarn global add standard-version
```

3 Настройка git

3.1 Первичная настройка параметров git

Зададим имя и email владельца репозитория:

git config --global user.name "Name Surname"
git config --global user.email "work@mail"

Настроим utf-8 в выводе сообщений git:
```
git config --global core.quotepath false
```
Настройте верификацию и подписание коммитов git (см. Верификация коммитов git с помощью GPG).
Зададим имя начальной ветки (будем называть её master):
```
git config --global init.defaultBranch master
```

3.2 Дополнительные настройки

3.2.1 Работа с переносами строк

В разных операционных системах приняты разные символы для перевода строк:
- Windows: \r\n (CR и LF);
- Unix: \n (LF);
- Mac: \r (CR).
Посмотреть значения переносов строк в репозитории можно командой:
```
git ls-files --eol
```

Параметр autocrlf

Настройка core.autocrlf предназначена для того, чтобы в главном репозитории все переводы строк текстовых файлах были одинаковы.
Настройка core.autocrlf с параметрами true и input делает все переводы строк текстовых файлов в главном репозитории одинаковыми.
- core.autocrlf true: конвертация CRLF->LF при коммите и обратно LF->CRLF при выгрузке кода из репозитория на файловую систему (обычно используется в Windows).
- core.autocrlf input: конвертация CRLF->LF только при коммитах (используются в MacOS/Linux).

Варианты конвертации

Таблица 1: Варианты конвертации для разных значений параметра core.autocrlf

core.autocrlf	false	input	true
git commit	LF -> LF	LF -> LF	LF -> CRLF
	CR -> CR	CR -> CR	CR -> CR
	CRLF -> CRLF	CRLF -> LF	CRLF -> CRLF
git checkout	LF -> LF	LF -> LF	LF -> CRLF
	CR -> CR	CR -> CR	CR -> CR
	CRLF -> CRLF	CRLF -> CRLF	CRLF -> CRLF

Установка параметра:

Для Windows
```
git config --global core.autocrlf true
```

Для Linux

git config --global core.autocrlf input

Параметр safecrlf
- Настройка core.safecrlf предназначена для проверки, является ли окончаний строк обратимым для текущей настройки core.autocrlf.
  - core.safecrlf true: запрещается необратимое преобразование lf<->crlf. Полезно, когда существуют бинарные файлы, похожие на текстовые файлы.
  - core.safecrlf warn: печать предупреждения, но коммиты с необратимым переходом принимаются.
- Установка параметра:
```
git config --global core.safecrlf warn
```

4 Практический сценарий использования git

4.1 Создание репозитория git

4.1.1 Подготовка каталога

Рабочий каталог будем обозначать как workdir. Вначале нужно перейти в этот каталог:
```
cd workdir
```
Создаём заготовку для файла README.md:
```
echo "# test-repo" >> README.md
git add README.md
```
Добавим шаблон игнорируемых файлов. Просмотрим список имеющихся шаблонов:
```
curl -L -s https://www.gitignore.io/api/list
```
Затем скачаем шаблон, например, для C и C++:
```
curl -L -s https://www.gitignore.io/api/c >> .gitignore
curl -L -s https://www.gitignore.io/api/c++ >> .gitignore
```
Можно это же сделать через web-интерфейс на сайте https://www.gitignore.io/.
Добавим файл лицензии. В данном случае мы выбираем лицензию CC-BY-4.0 (см. Выбор лицензии для научной работы):
```
wget https://creativecommons.org/licenses/by/4.0/legalcode.txt -O LICENSE
```
Если выбирается лицензия CC-BY-SA-4.0, то нужно выполнить:
```
wget https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt -O LICENSE
```
Инициализируем системы git:
```
git init
```

4.1.2 Подключение репозитория к github

Создайте репозиторий на GitHub. Для примера назовём его test-repo.

Делаем первый коммит и выкладываем на github:

git commit -m "first commit"
git remote add origin git@github.com:<username>/test-repo.git
git push -u origin master

4.1.3 Конфигурация общепринятых коммитов

Конфигурация для пакетов Node.js
```
yarn init
```
Необходимо заполнить несколько параметров пакета.
- Название пакета.
- Лицензия пакета. Список лицензий для npm: https://spdx.org/licenses/. Предлагается выбирать лицензию CC-BY-4.0.

Сконфигурим формат коммитов. Для этого добавим в файл package.json команду для формирования коммитов:

"config": {
        "commitizen": {
            "path": "cz-conventional-changelog"
        }
}

Таким образом, файл package.json приобретает вид:

{
        "name": "test-repo",
        "version": "1.0.0",
        "description": "Git repo for educational purposes",
        "main": "index.js",
        "repository": "git@github.com:username/test-repo.git",
        "author": "Name Surname <username@gmail.com>",
        "license": "CC-BY-4.0",
        "config": {
            "commitizen": {
                "path": "cz-conventional-changelog"
            }
        }
}

Добавим новые файлы:
```
git add .
```
Выполним коммит:
```
git cz
```
Отправим на github:
```
git push
```

4.1.4 Конфигурация git-flow

Инициализируем git-flow
```
git flow init
```
Префикс для ярлыков установим в v.
Проверьте, что Вы на ветке develop:
```
git branch
```
Загрузите весь репозиторий в хранилище:
```
git push -u --all
```
Создадим релиз с версией 1.0.0
```
git flow release start 1.0.0
```
Создадим журнал изменений
```
standard-changelog --first-release
```

Добавим журнал изменений в индекс

git add CHANGELOG.md
git commit -am 'chore(site): add changelog'

Зальём релизную ветку в основную ветку
```
git flow release finish 1.0.0
```
Отправим данные на github
```
git push --all
git push --tags
```
Создадим релиз на github. Для этого будем использовать утилиты работы с github (см. github: утилиты командной строки):
```
gh release create v1.0.0 -F CHANGELOG.md
```

4.2 Работа с репозиторием git

4.2.1 Разработка новой функциональности

Создадим ветку для новой функциональности:
```
git flow feature start feature_branch
```
Далее, продолжаем работу c git как обычно.
По окончании разработки новой функциональности следующим шагом следует объединить ветку feature_branch c develop:
```
git flow feature finish feature_branch
```

4.2.2 Создание релиза git-flow

Создадим релиз с версией 1.2.3:
```
git flow release start 1.2.3
```
Обновите номер версии в файле package.json. Установите её в 1.2.3.
Создадим журнал изменений
```
standard-changelog
```