|
|
|
## Требования
|
|
|
|
|
|
|
|
Необходимо зарегистрироваться в:
|
|
|
|
|
|
|
|
* [Gitlab](https://gitlab.42dev.ru) (ГЛ) - управление версиями кода, ревью кода
|
|
|
|
|
|
|
|
Для регистрации в Gitlab следует предоставить:
|
|
|
|
|
|
|
|
* адрес почты
|
|
|
|
* логин
|
|
|
|
* имя
|
|
|
|
* фамилия
|
|
|
|
* указать в каких проектах и в какой роли (фронт, бэк, прочее)
|
|
|
|
|
|
|
|
После регистрации администратором или самостоятельно, следовать инструкции в письме или ждать согласования.
|
|
|
|
|
|
|
|
Следует изучить требования к разработке проекта (код-стайл - минимум).
|
|
|
|
|
|
|
|
## Процесс разработки
|
|
|
|
|
|
|
|
Рассмотрим процесс работы над проектами студии более подробно.
|
|
|
|
|
|
|
|
Ожидаются некоторые навыки работы с консолью и наличие установленного git-клиента. Есть способы работы с кодом и без консоли. Для Windows это, например, [TortoiseGit](https://tortoisegit.org/). Но для наглядности рассмотрим работу из консоли.
|
|
|
|
|
|
|
|
После регистрации и получения прав на редактирование репозитория, требуется клонировать себе проект локально, например:
|
|
|
|
|
|
|
|
```shell
|
|
|
|
git clone git@gitlab.42dev.ru:example-group/example-project.git
|
|
|
|
```
|
|
|
|
|
|
|
|
Ссылку можно скопировать со страницы проекта
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Далее следует выбрать ветку от которой будет вестись ветка с разработкой. Если куратор не определил другую, то эта ветка будет `master`. Например исходной веткой указана куратором не `master`, а `example-1`. Тогда следует выполнить в папке клонированного репозитория:
|
|
|
|
|
|
|
|
```shell
|
|
|
|
# ШАГ 1: создание ветки
|
|
|
|
git fetch
|
|
|
|
git checkout example-1 # переключение на родительскую ветку
|
|
|
|
git checkout -b dev-from-example-1 # создание своей ветки
|
|
|
|
```
|
|
|
|
|
|
|
|
> Название ветки должно быть содержательным (по названию ветки должно быть понятно какие изменения в ней). Название может состоять только из латинских букв нижнего регистра, цифр и знака `-`.
|
|
|
|
|
|
|
|
Так была создана ветка разработки и репозиторий переключен на неё.
|
|
|
|
|
|
|
|
После этого можно разрабатывать (менять код) и коммитить. Обычно этот процесс выглядит примерно так:
|
|
|
|
|
|
|
|
```shell
|
|
|
|
# ШАГ 2: работа с кодом
|
|
|
|
# какие-то файлы изменены, получен какой-то промежуточный или конечный результат
|
|
|
|
git diff # смотрим, что у нас поменялось
|
|
|
|
git add . # можно указать конкретные файлы, здесь указаны все
|
|
|
|
git commit -m 'Здесь пишется что меняет коммит'
|
|
|
|
git status # так можно проверить результат коммита
|
|
|
|
# когда получен конечный ожидаемый результат можно записать в удаленный репозиторий
|
|
|
|
# но сначала:
|
|
|
|
git pull origin example-1
|
|
|
|
# если в родительской ветке что-то менялось, то могут возникнуть конфликты
|
|
|
|
# следует их разрешить, вновь закоммитить и сделать пул и только потом:
|
|
|
|
git push origin dev-from-example-1
|
|
|
|
```
|
|
|
|
|
|
|
|
Далее следует создать в GitLab-е Merge request (MR). Для этого можно пройти по пункту меню "Repository" -> "Commits" и переключить ветку на вашу (в примере выше - `dev-from-example-1`) после чего нажать кнопку "Create merge request". В форме создания MR следует выбрать свою ветку `dev-from-example-1` в `From` и `example-1` в `into`. Можно написать более развернутое описание набора предлагаемых коммитов и более релевантное название MR. Желательно выбрать чекбокс "Delete source branch when merge request is accepted".
|
|
|
|
|
|
|
|
После создания MR куратор и назначенные им ревьюеры проверят MR и если замечаний нет, то работу можно считать законченной. Если есть замечания, то их следует обсудить/устранить. Для устранения замечаний повторяется "ШАГ 2".
|
|
|
|
|
|
|
|
> Не следует размещать в репозитории большие файлы без острой необходимости. Если у вас есть файл больше 50 мегабайт - обсудите с куратором целесообразность его размещения в репозитории. |
|
|
\ No newline at end of file |
