Хорошая стратегия для обработки зависимостей между последовательными запросами на растяжение

Question

Боб клонирует проект и создает локальную ветвь A от master.

Боб добавляет несколько полезных классов очистки/рефакторинга классов вспомогательных классов, а также очищает все выходящие тесты благодаря им.

Боб совершает переход на удаленный сервер, затем создает запрос на перенос, чтобы получить обзор кода этого рефакторинга от Джона.

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

После запроса обзора кода Боб хочет написать несколько новых тестовых файлов, а набор классов заканчивается другим разделенным запросом на разрыв, так как считается, что он работает над новой функцией.
Очевидно, что Боб хочет использовать своих новых помощников для этих тестовых файлов.

Какой стратегии принять:

• Для этих новых модульных тестов, Боб должен создать B ветви происходит от master и не A поскольку A еще не рассмотрена. Недостатком является то, что он не может использовать своих вспомогательных помощников по модулю, так как не существует в B.

• Боб должен дождаться обзора кода первого запроса на извлечение, слить до master, а затем получить B от master. В течение этого времени он должен сосредоточиться на других работах, которые не зависят от его предыдущего запроса на растяжение.

• Боб должен получить B от A и использовать эти помощники, рискуя, что A не будет принят после проверки. Очевидно, что приводит к отказу от B.

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

Что такое хорошая практика для обработки зависимостей между несколькими запросами на тягу в серии?

Answer 1

Не нужно зависеть и ждать вашего текущего запроса на тягу (PR) на предыдущие. Для вашей ситуации Боб хочет продолжить разработку/тестирование чего-либо на основе филиала A после обработки PR (выпущено и еще не утверждено). Ему просто нужно разработать код на ветке A, а затем зафиксировать & push to remote. PR, который объединяет ветвь A в master, автоматически будет содержать изменения во втором времени Боба.

Так что для ситуации множественного PR, если вы хотите обновить ветку, которая уже в запросе тянуть, вам просто необходимо совершить & изменений толчка, предыдущий PR может обновляться автоматически. Если вы хотите обновить ветвь, которая не содержится в обработке PR, вам необходимо зафиксировать & push changes, а затем создать новый PR, и это не повлияет на предыдущий PR обработки.

Если вы просто хотите добавить небольшие изменения или самую функцию, вы должны внести изменения в ветку A и использовать обработку PR.Если вам нужно разрабатывать новые функции, вы должны внести изменения в новую ветку функций и создать новый PR.

Для состояния Боба, разработки новой функции и нужно использовать помощник по отрасли A, поэтому он должен получить ветвь B от A даже A еще не рассмотрен. Потому что разработчикам необходимо подумать о том, как разработать новую функцию, и неэффективно разрабатывать новую функцию до тех пор, пока не будет одобрен предыдущий PR. Или, если вашей команде действительно нужно использовать этот способ, вы все равно можете получить B от A и переделать ветку B для своих нужд.