Локальний перегляд pull-реквесту
Перегляд діфа в браузері каже вам, чи добре читається код. Він не каже, чи застосунок усе ще запускається. Щоб дізнатися це, доводиться запустити гілку — і саме тут люди застрягають, бо pull-реквест із форка живе в репозиторії, який ви ніколи не клонували, а часто ще й не маєте права туди пушити.
Локальний перегляд розв’язує це завдяки факту, який більшості ніколи не доводиться вчити: хостинги публікують head кожного pull-реквесту як звичайний git-реф у цільовому репозиторії. Форк не мусить бути досяжним, API-токен не потрібен, і жоден другий ремоут не додається. Один фетч — і код у вас на диску.
| Хостинг | Де живе head пул-реквесту |
|---|---|
| GitHub, GitHub Enterprise, Gitea, Forgejo, Gogs | refs/pull/<n>/head |
| GitLab (хмарний і самостійно розгорнутий) | refs/merge-requests/<n>/head |
| Bitbucket Cloud, Bitbucket Server | refs/pull-requests/<n>/from |
| Azure DevOps | refs/pull/<n>/merge |
Gitcito перевіряє всі чотири за один ls-remote, тож незнайомий або самостійно
розгорнутий хостинг працює, доки він дотримується однієї з цих конвенцій.
Як його відкрити
- Список pull-реквестів на бічній панелі — кнопка зі стрілкою на будь-якому записі. Це працює для кожного хостингу, на відміну від детального вигляду, який є лише для GitHub.
- Палітра команд: Переглянути pull-реквест локально.
- Усередині детального вигляду pull-реквесту, поруч із кнопкою «відкрити в браузері».
Що ви йому даєте
Ремоут — репозиторій, проти якого відкрито pull-реквест, зазвичай
origin. Не форк.
Pull-реквест — номер або вставлений URL із браузера. 7, #7 і
https://github.com/owner/repo/pull/7 — усе працює; так само й форми URL для
GitLab, Bitbucket та Azure DevOps. Натисніть Знайти, і Gitcito повідомить,
який реф він розв’язав і на який коміт той вказує, ще до того, як щось буде
зафетчено.
Віддалена гілка — друга вкладка, для випадків, коли жодного PR-рефа не знайти: хостинг, який їх не публікує, або гілка, яку ви просто хочете спробувати. Вкажіть назву гілки такою, якою вона є на ремоуті.
Два способи застосувати
Жоден із них не пише коміт. Це навмисно — перегляд, від якого не можна просто піти, це не перегляд.
| Режим | Що відбувається | Як це скасувати |
|---|---|---|
| Локальна гілка | Реф фетчиться на власну гілку (типово pr/7), і на неї робиться чекаут. Інші ваші гілки лишаються недоторканими. |
Скасування повертає вас на гілку, де ви були, і видаляє гілку перегляду. |
| Незакомічене злиття | Реф зливається в поточну гілку з --no-commit --no-ff, і об’єднане дерево лишається проіндексованим, щоб ви могли його зібрати й протестувати. |
Скасування перериває злиття. |
Повторний перегляд того самого pull-реквесту використовує ту саму гілку, пересуваючи її на новий head — зручно, коли автор пушить виправлення, поки ви тестуєте. Якщо така гілка вже існує, Gitcito каже про це і питає, перш ніж її скидати, бо будь-який коміт, що живе тільки там, було б утрачено.
Чого він не робить
- Він не може вигадати реф, якого хостинг не публікує. Деякі самостійно розгорнуті конфігурації вимикають PR-рефи; у деяких хостингів їх ніколи й не було. Ви отримаєте зрозуміле «немає рефа для #n» і вкладку віддаленої гілки як шлях далі.
- Він не фетчить теги. Перегляд не повинен тягнути чужий простір імен тегів у ваш репозиторій.
- Режим злиття потребує чистого робочого дерева. Git відмовляється зливати поверх незакомічених змін; спершу зробіть стеш.
- Перегляд — це не рев’ю. Він кладе код на вашу машину — він нічого не схвалює, не коментує і не зливає. Це хостинг та pull-реквести.
- Приватні форки лишаються приватними. PR-реф віддає цільовий репозиторій, тож доступ визначається вашими обліковими даними саме для того ремоута — дивіться безпеку.
Прибирання
Гілка перегляду — це звичайна гілка: видаліть її з бічної панелі, коли закінчите, або натисніть скасування одразу після перегляду. Незакомічене злиття перегляду можна відкинути скасуванням, а можна розв’язати й закомітити, якщо ви все-таки вирішили, що воно вам потрібне, — і в цю мить воно перестає бути переглядом і стає злиттям.