Зачем использовать пул-запросы вместо слияния


16

В чем преимущество использования запросов извлечения вместо простого объединения ветки в мастер без таковой? Особенно в команде, где все разработчики имеют полный доступ к мастеру.


1
Запросы на извлечение позволяют руководителю проекта решить, хотят ли они объединить ветку в основную или нет.
Роберт Харви

На практике, если все разработчики имеют доступ к мастеру, это имеет значение?
Гусь

2
@ Goose Code обзор?
няня

4
Мы не используем запросы на извлечение в нашем магазине. Насколько я понимаю, Pull Requests в основном используются на Github, где у вас есть открытый проект с открытым исходным кодом. Как руководитель проекта такого проекта, вместо того, чтобы дать всему миру полную свободу действий над вашим проектом для внесения произвольных (и потенциально вредных) изменений, вы вместо этого требуете от людей представлять свои изменения в форме запросов на извлечение, чтобы вы могли просмотреть их изменения, прежде чем объединить их в главную ветку.
Роберт Харви

4
Потому что это способ DVCS никогда не делать за один простой шаг то, что вы можете сделать за 3 или 4 сложных шага
Мейсон Уилер

Ответы:


23

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

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

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

Выработка привычки использовать запросы извлечения может также помочь вашей команде, если вы в будущем решите, что вся команда не должна иметь доступа к мастеру. Если ваша команда становится больше, и особенно если у вас есть члены команды, которые являются новичками в продукте и / или новичками в Git, отказ от предоставления им доступа к мастеру может быть безопаснее для целостности продукта.


5

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

Они предлагают хороший механизм и интерфейс для проверки кода, но также усложняют и замедляют весь процесс «завершения работы». Особенно, если у вас есть много мелких функций, каждая из которых ожидает проверки, объединения, а затем все остальные объединяются с мастером снова, чтобы вытащить изменения и т. Д. Если у вас есть большие функции, тогда их становится сложно просмотреть, поэтому вы попали в тупик ,

Сказав, что вы можете делать пул-запросы между филиалами в одном репо. Вам не нужно разветвляться или иметь разные разрешения.

Кроме того, вы должны рассмотреть всю методологию и рабочий процесс. У вас также есть система тикетов, CI, автоматические приемочные тесты и т.д.? Ваши обзоры кода обеспечивают жизненно важную проверку перед вводом кодов в действие, или это просто упражнения с штампом, которые становятся ненужными из-за других проверок в вашем рабочем процессе?


4

Существует наблюдение под названием Закон Конвея, которое гласит:

организации, которые разрабатывают системы ... вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций.

Какое это имеет отношение к запросам на включение? Тяговые запросы являются основным каналом связи в критическом соединении для вашего кода. Они предоставляют возможность для анализа, автоматического тестирования и улучшения, прежде чем код перейдет к следующим этапам тестирования и производства, где эти изменения намного сложнее отбросить, и тратит гораздо больше времени на гораздо больше людей.

Аналогичным образом, закон Конвея предлагает, если вы хотите иметь микросервисную архитектуру с четко разделенными областями автономной ответственности и четко определенными интерфейсами, то каналы связи вашей организации должны отражать архитектуру, которую вы хотите достичь. Это означает, что небольшие группы из 5-10 человек должны иметь прямой доступ к любому микросервису, и любой, кто не входит в эту группу, должен пройти запрос на извлечение. Это гарантирует, что люди, наиболее знакомые с микросервисом, будут рассматривать и консультировать его.

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

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


1

Карл Билефельдт совершенно прав. Я бы добавил: все дело в качестве.

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

Это действительно стоит усилий.


Спасибо за ваш комментарий. Я не уверен, почему применять это как ответ на вопрос.
Гусь

Это единственный ответ с упоминанием CI перед слиянием.
Basilevs

0

Мы используем запросы извлечения для проверки кода - код не следует объединять с основной веткой разработки (обычно в нашем случае это «разработка», но иногда «мастер»), не выполняя запрос на извлечение. Мы не навязываем это жестко с помощью средств управления хранилищем, но это потому, что нам не нужно - наши разработчики достаточно зрелы, чтобы не злоупотреблять процессом.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.