Навіщо використовувати запити на тягнення замість злиття

Яка перевага використання запитів на витяг, а не просто об’єднання гілки в головний без одного? Особливо в команді, де всі розробники мають повний доступ до майстра.

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

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

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

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

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

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

Сказавши, що ви можете робити запити між гілками одного і того ж репо. Вам не потрібно розщедритися або мати різні дозволи.

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

Існує спостереження під назвою Закон Конвея, в якому сказано:

організації, які проектують системи ... обмежуються виробляти конструкції, які є копіями структур зв'язку цих організацій.

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

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

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

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

Карл Білефельдт абсолютно правий. Я додам: це все стосується якості.

У багатьох (у більшості?) Магазинах немає офіційних процесів для управління розвитком, що призводить до: "Я працював у середовищах, де не можу нічого зробити протягом тижня, тому що збірка завжди порушена, і я працював в умовах, коли хтось подає запит на тягнення, і мені навіть не потрібно його переглядати, оскільки вони порушили збірку CI, і я вам кажу, вони варті кожної секунди зусиль ".

Це дійсно варто докласти зусиль.

Ми використовуємо запити на тягу для перегляду коду - жоден код не повинен бути об'єднаний у головну галузь розробки (як правило, "розробляти" у нашому випадку, але іноді "майстер"), не пройшовши запит на витяг. Нам не важко застосувати це за допомогою контролю репозиторію, але це не тому, що нам не доведеться - наші розробники досить зрілі, щоб не зловживати цим процесом.