Чи краще запустити Запит на виклик або виконати локальне злиття на майстер?

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

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

Отже, що я повинен робити при об'єднанні функції-гілки в головну:
Виконайте об'єднання-компіляцію на master та потім натисніть її вгору за течією АБО Натисніть на локальну гілку та запустіть Запит на тягу?

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

— Ашхар Хасан
джерело

Що саме вам не вистачає з цих відповідей?

— RubberDuck

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

— Ашхар Хасан

Я дивлюся на це з кращих практик або як підтримувати гарну точку зору історії git .

— Ашхар Хасан

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

— амон

Коли PR об'єднується, він створює об'єднання для master, тому я не думаю, що це має ніяке значення для історії git. Таким чином, я не думаю, що немає жодних причин використовувати те чи інше, окрім ваших особистих переваг між командним рядком та інтерфейсом Github.

— Іксрек

Відповіді:

механізм git-merge:
Використання git merge featureв режимі master об'єднує гілку featureдо masterта створює merge-commit(якщо гілку неможливо швидко переслати) в історії git. Щоб змусити merge-commitбути створеним, скористайтеся --no-ffопцією с merge.

Механізм злиття запиту на об'єднання:
Коли ми запускаємо запит на виклик на GitHub, він створює місце, GitHub Issueде люди можуть говорити та обговорювати зобов’язання в PR, перш ніж об'єднати його. Коли PR об'єднується на GitHub, він робить точно так само, як і git merge feature.

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

Найкращі практики:
І мені не вдалося знайти кращих практик, але логіка говорить, що PR не дуже корисні, якщо в сховищі є лише одна людина.

@lxrec і @amon допомогли мені дійти цього висновку.

— Ашхар Хасан
джерело

Порада: git mergeможе не записати об'єкт злиття, якщо він може зробити "швидкий вперед". Щоб примусити здійснити об'єднання, ви можете додати --no-ffопцію.

— amon

Я вважаю за краще робити git-merge на локальному, а не робити це на githuib.com, якщо мені доведеться щось подібне на github.com, я б вважав за краще не робити безпосередньо на головній гілці, я б скоріше взяв не master master, який може спочатку встановлювати в режимі постановки, перш ніж зробити його доступним для виробництва.

— Ciasto piekarz

Як сказав Ашхар , різниці в технічному плані немає. Для проектів з невеликою командою я віддаю перевагу об'єднанню безпосередньо замість додаткового кроку створення PR. Однак, коли функція потребує огляду / зворотного зв’язку або коли це WIP, і над нею працюватиме більше однієї людини, я схильний відкривати PR та додавати перелік завдань до опису PR.

Зауважте, що git mergeможливо використовувати швидку перемотку вперед, якщо не буде змін для головного, так що ви можете використовувати git merge --no-ff. Я, як правило, не так.

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

— Луї Алакад
джерело

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

— Ерік