Праца з Pull Request

Pull request review вырашае некалькі важных задач:

1. Распаўсюд ведаў пра кодавую базу
2. Паляпшэнне якасці кода

Працэс рэв'ю можа складацца з адной ці некалькіх ітэрацый: часта рэв'ювер можа спытаць нешта змяніць у кодзе ці прыясніць нейкія моманты перад тым як прыняць ПР:

Умовы прыняцця Pull request

1. Зялёны білд: усе праверкі мусяць праходзіць
2. Ясныя мэты: ЧАМУ вы зрабілі гэтыя змены/стварылі ПР?
3. Чысты-код: Код добра чытаецца і ўсе змены тычуцца ТОЛЬКІ арыгінальнай issue

Зялёны білд

Мы выкарыстоўваем некаторыя аўтаматызаваныя сэрвісы для запуску тэстаў і праверкі кода (код-стайл, якасць кода і т.п.). Сэрвісы звычайна запускаюць праверку пасля кожнага каміта, у тым ліку каміта для ПР. Каб прыняць ПР ваш код мусіць праходзіць усе праверкі. Прыклад ПР які не праходзіць праверку ("упалі" тэсты):

Каб зразумець што не так з вашым камітам ці ПР і чаму ён не праходзіць праверку - клікайце на "Details" ці па чырвонаму крыжыку каля ID вашага апошняга каміта (у інтэрфейсе GitHub).

Ясныя мэты

Вашы змены, і, галоўнае, вашы памкненні мусяць быць зразумелымі таму, хто будзе рэв'ювіць ваш код. Каб спрасціць гэты працэс, калі ласка факусуйцеся на адказе на пытанне "ЧАМУ?": ЧАМУ вы прынялі такое рашэнне, ЧАМУ раней не працавала а зараз будзе, ЧАМУ нам трэба гэты функцыянал ці бібліятэка і т.п.

Чысты код

Якасць кода мае значэнне. На жаль не ўсё можна пратэсціць аўтаматыкай.