Skip to content

Latest commit

 

History

History
55 lines (30 loc) · 5.1 KB

MergeRequest.md

File metadata and controls

55 lines (30 loc) · 5.1 KB

Mege Request. Что это, зачем, и как его оформлять

Вы написали код. Оформили документацию. Нарисовали великолепный интефейс. Что дальше?

Если вы кинете результат своих трудов в ревьюера с фразой "я сделяль", то скорее всего, он будет не очень доволен.

В данном файле будет описано, что сделать, когда вы закончили делать свою задачу

P.S. PR (Pull request) и MR (Merge request) - это синонимы и обозначают одно и то же

Создание MR

Код, что вы создали, располагается в ветке. Ветка представляет собой некий результат работы.

Данный результат вашей работы будет проверять ревьюер. Подробнее про процесс ревью описано в файле про процесс ревью.

  1. Необходимо открыть страницу создания merge-request.

    Окно создания МР

  2. Выбрать ветки, которые будут использованы. base это куда будут вливаться изменения (у нас это всегда main), а вторая это ваша ветка с задачей.

    Окно выбора веток

  3. Написать сообщение к МР, взяв темплейт в следующем файле.

    Сообщение к МР должно отвечать на вопросы: к какой задаче этот МР, кто его делал, кто (по навыкам) должен его проверять. А так же, что в МР сделано (если будут проблемы, то просматривая этот пункт у закрытых МР, можно будет понять какой МР вызывал проблемы).
    А так же, самое главное, что стоит обращать внимание ревьюеру, что ему стоит пристально проверить. К примеру, человек, пишущий документацию, может попросить у того, кто лучше всех знает что делать, проверить пункты ТЗ, что вызывают у него сомнения. МР можно создать и в начале работы над задачей. Ревьюер просмотрит МР только в том случае, если задача находится на ревью

    Пример оформления МР (обратите внимание на подчеркивание красным)

  4. Нажать кнопку "Create Pull Request". После этого, МР будет созданным и готовым к ревью. Ждите похвал или комментариев.

Стоит понимать, что отдавая задачу на ревью, вы отдаваёте результат своей работы, он должен быть таким, чтобы его можно было использвовать. Самый простой способ понять, все ли нормальо - это представить, что вам нужно будет воспользоваться тем, что вы сделали, представить себя на месте другого человека, что будет использовать ваш труд. Если вы делаете делаете документацию, представьте себя на месте UI дизайнера, что будет на осове вашей документации делать в фигме UI интерфейс или программиста, что будет писать бизнес-логику. Если вы UI дизайнер, представьте себя на месте конечного пользователя, что будет использовать интерфейс и программиста, что должен понять, что от него требуется сверстать. Если вы можете утвердительно ответить на вопрос "достаточно ли того, что я написал, человеку что будет это использовать?", то вы все сделали верно и вы молодцы.