Чи є мета використання запитів на тягнення до мого власного репо, якщо я єдиний розробник?

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

Тепер, коли я натискаю свою гілку на GitHub, у мене є той розділ, у якому є дві кнопки: Pull Requestі Compareз назвою гілки, на яку я нещодавно натиснув. Я розумію призначення Compareкнопки, але не розумію, чому я хотів би створити запит на тягнення на власному репо.

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

Для багатьох (можливо, більшості) окремих розробників, які працюють самостійно, створювати запити на тягування, мабуть, не варто. Однак я можу придумати хоча б одну можливу причину цього:

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

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

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

Створюються запити на виклик, щоб хтось міг переглядати роботу, робити коментарі, пропозиції, вносити чи вимагати правки, а потім об'єднати код у головне

У вашому випадку хтось - це ви.

Як єдиний розробник ви все-таки повинні переглянути власну роботу, переробляти її та зливати її, коли вона буде готова.

Один із підходів, який я багато використовую, - це спробувати «надіти іншу шапку», «спробувати інших персон». Тому ненадовго посидьте і поставте себе в ситуацію: новачка в групі; молодший розробник; колега, якого ви поважали в минулому і т. д. Спробуйте поглянути на це їх очима і спробуйте подумати про те, що ви могли зробити, щоб зробити зміни більш очевидними, краще писати з ще кращими іменами, які максимально уникають племінних і доменних знань. .

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

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

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

Це правила, а не правила, яких слід дотримуватися. Я навмисно їх інколи ламаю. Наприклад, вчора я вчинив виправлення помилок друку.

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

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

Запити на виклик зазвичай використовуються як для огляду коду, так і для вкладів користувачів із власною вилкою проекту - для одного розробника в проекті я дійсно не бачу мети.

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

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

Загалом, це спосіб підключення гаків для завершення змін. Тести - приклад; @John згадав створення нотаток до випуску як інший приклад.

Запити на витяг проти git push в кінцевому рахунку зводиться до однієї окремої або спільної історії. Головне сховище є джерелом для всіх змін, якщо інші витягують з себе та потенційно вносять локальні зміни, то натискання запиту може викликати проблеми цих користувачів як дерево, яке вони походять від змін.

Модель запиту на виклик (з користувацьких відділень або особистих сховищ) служить способом надання послідовної історії для всіх, хто використовує та виходить з коду.

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