✅ WEB і WordPress новини, теми, плагіни. Тут ми ділимося порадами і кращими рішеннями для сайтів.

Як використовувати шаблони GitHub PR

11

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

Для багатьох із вас ви або стежите за проектом, берете участь у проекті або обробляєте запити на підключення до проекту. А як щодо тих проектів, над якими ви працюєте з командою?

Можливо, ваш робочий процес виглядає приблизно так:

  • ви створюєте гілку для роботи над функцією,
  • ви натискаєте на гілку, щоб деталізувати роботу, яку ви виконали, для перегляду колегами,
  • огляд об’єднано,
  • ти продовжуєш.

Але що ви розміщуєте в шаблоні запиту на отримання? Щоразу однаково чи по-різному? Що робити, якщо вміст PR пов’язаний із чимось у Trello, Asana, Basecamp чи іншій системі керування проектами?

Ось тут і вступають у гру PR-шаблони GitHub.

Шаблони GitHub PR

Ви можете прочитати все про них на сторінці, але ось суть (без каламбуру):

Важко вирішити проблему, коли не вистачає важливих деталей. Тепер супроводжувачі проектів можуть додавати шаблони для проблем і запитів на вилучення до проектів, допомагаючи учасникам ділитися потрібними деталями на початку потоку

А ідея проста: ми створюємо шаблони для проблем і запитів на отримання для інших, які надають певний рівень інформації, який вони повинні заповнити, перш ніж надсилати проблему чи запит на отримання.

Це допомагає нам, оскільки супроводжувачі знають будь-яку інформацію, яка нам потрібна, перш ніж її вивчати. Крім того, це може дозволити нам зробити посилання на попередній випуск, попередній квиток, будь-що раніше, пов’язане з проектом.

Наприклад, скажімо, ви працюєте над проектом і хочете включити таку інформацію:

  • короткий опис того, що робить PR, щоб супроводжуючому не довелося здогадуватися,
  • статус PR щодо того, чи має він бути готовий до об’єднання, чи він все ще в розробці, але готовий до деякого перегляду,
  • посилання на заявку в менеджері проекту, до якого відноситься PR.

Я не кажу, що це та інформація, яка потрібна, але це те, що ми використовували, і я знайшов його корисним (і приємно бачити, що з часом вноситься більше вдосконалень ).

Але як ми це використовуємо?

Сайт досить зрозумілий, але дуже простий. Вам потрібні наступні файли в каталозі вашого проекту або в папці. каталог github :

  • ISSUE_TEMPLATE
  • PULL_REQUEST_TEMPLATE

Кожен із них має бути файлом розмітки, у якому вказується саме те, що ви бажаєте включити своїм співавторам, коли вони, знаєте, певним чином роблять внесок у ваш проект.

І потім, щоразу, коли користувач хоче повідомити про проблему або створити запит на отримання, він запитує інформацію з шаблону.

Гарно, чи не так?

Це небагато, але…

Ви можете не думати, що це багато, але це досить легко допомогти покращити якість інформації, що надходить до проекту, змусити ваших співавторів подумати про те, що вони вкладають у проект, а потім відповідати відповідним чином.

Крім того, це допомагає вам і решті вашої команди зрозуміти, що саме збирається переглянути, і підготуватися до будь-яких змін, які можуть відбутися під час роботи над цими проектами.

Джерело запису: tommcfarlin.com

Цей веб -сайт використовує файли cookie, щоб покращити ваш досвід. Ми припустимо, що з цим все гаразд, але ви можете відмовитися, якщо захочете. Прийняти Читати далі