Хостинг та pull-реквести

Створення

Створіть pull- (або merge-) реквест, не покидаючи застосунку: випадні списки гілок, заголовок і тіло, заздалегідь заповнені з комітів гілки, перемикач чернетки і — на GitHub — рецензенти, мітки та виконавці, застосовані одразу під час створення.

Створення pull-реквеста

Працює на GitHub, GitLab, Bitbucket і Azure DevOps. Відкриті PR/MR для всіх чотирьох показані на бічній панелі.

Почніть із порівняння гілок, із графа, з + у панелі PR або із задачі (яка підставить Closes #N).

Стеки у списку

Pull requestʼи, що стоять один на одному, згортаються в один рядок: піктограма стека, гілка, на яку приземляється ланцюг, і скільки їх. Розгорніть — і побачите ланцюг у порядку читання, від вершини до основи, а під кожним рядком маленьку стрілку з тим, у що він вливається: напрям на екрані, а не виводиться з чотирьох баз.

Групу задають дві речі: власний номер стека GitHub, якщо pull requestʼи входять до нативного стека, а інакше самі посилання — pull request, чия база є головою іншого, стоїть на ньому. Друге правило й робить це робочим на GitLab, Bitbucket та Azure DevOps.

Стек у списку pull requestʼів

У кожному рядку — стан перевірок його голови (наведіть, щоб побачити числа), а на GitHub ще й рівні, вже закриті чи влиті, які список відкритих PR сховав би. Рівень над закритим позначається заблокованим: його власні перевірки можуть бути зеленими, але гілка, на яку він націлений, уже ніколи не приземлиться. Дії рядка зʼявляються при наведенні, щоб заголовку вистачало ширини.

Читання перевірок коштує один запит на pull request і лише під час оновлення списку.

Рев’ю — GitHub і GitLab


Обговорення	Коментарі та стан рев’ю
Перевірки	Прогони CI (GitHub) або завдання пайплайна (GitLab) зі статусами пройдено/провалено/очікує та посиланнями на логи
Переглянуті файли	Чек-лист із ✓ на кожен файл і прогресом
Гілки коментарів	Коментарі до рядків, згруповані за `file:line`, і відповіді
Дії	Коментувати, схвалити, запросити зміни та злити / squash

Якщо хтось зробив примусовий пуш посеред рев’ю, що змінилося відтоді покаже вам, що саме зрушило.

Відмінності GitLab, названі прямо: у GitLab немає єдиного виклику «надіслати рев’ю», тож схвалити використовує його ендпоінт схвалень, а запросити зміни знімає ваше схвалення й публікує ваш коментар. Rebase-merge не пропонується — GitLab сам обирає між merge-комітом і fast-forward за налаштуваннями проєкту, тому в меню злиття лише merge і squash. Гілки коментарів показують файл і рядок, але не навколишній ханк діфа, якого API GitLab не повертає. Рев’ю та злиття працюють для проєктів на gitlab.com; self-hosted-інстанси поки не підтримуються. Bitbucket і Azure DevOps для рев’ю досі відкриваються в браузері.

Задачі, віхи, релізи — GitHub

Переглядайте задачі й відкривайте повноцінну вкладку задачі: тіло, коментарі, мітки, виконавці, віха, поля Projects v2, закриття/перевідкриття і створення гілки для цієї задачі (з назвою від ШІ). Віхи показують прогрес і свої задачі. Релізи можна переглядати разом зі сторінкою змін.

Сповіщення — GitHub

Уся ваша вхідна скринька — запити на рев’ю, згадки, активність CI — по всіх репозиторіях, із фільтрами непрочитаного/усього та позначенням як прочитане. Дзвіночок на панелі носить бейдж непрочитаного, а за бажанням спрацьовують і системні сповіщення, коли у вас просять рев’ю або коли завершується CI.

Токени

Окремі токени для кожного профілю — для кількох облікових записів чи організацій — зберігаються в keychain вашої ОС. Gitcito також уміє позичити те, що вже тримає ваш помічник облікових даних git, тож організація, для якої ви вже пройшли автентифікацію, часто взагалі не потребує налаштування. Дивіться Безпеку та секрети.

Дивіться також: Стековані гілки · Можливості ШІ