В потоке GitHub это нормально, чтобы основать ветвь функции на другой ветви функции?

Мы используем GitHub Flow в нашем проекте, и большую часть времени мы открываем новую ветку функций от master , выполняем там некоторую работу, открываем PR, просматриваем код и возвращаемся в master .

Однако моя текущая работа зависит от другой проблемы, над которой мы работаем feature-branch-A. Кошерно ли создавать мою ветку из этой другой ветки или это против духа GitHub Flow?

Альтернативой было бы основать мою ветку на master и объединить изменения feature-branch-A(часто).

Какой вариант предпочтителен в потоке GitHub?

Вот рабочий процесс, которому я следую при переходе из функциональной ветви:

1. Создать feature-branch-Bизfeature-branch-A
2. Работа над feature-branch-B
3. Если feature-branch-Aпосле ветвления добавлено больше коммитов, перебазируйте feature-branch-Bнаfeature-branch-A
4. Завершите работу feature-branch-Bи дождитесь feature-branch-Aслияния master.
5. После feature-branch-Aслияния masterперебазировать feature-branch-Bнаmaster
6. Слить feature-branch-Bвmaster

Следуя вышеуказанному рабочему процессу, вы увидите, что вы ответвились masterпосле feature-branch-Aслияния. Вам не нужно ждать feature-branch-Aслияния, чтобы начать работу feature-branch-B. Тем не менее, вы получите чистую историю без каких-либо сложных деревьев.

Я думаю, что это совершенно нормально, если вы создаете функцию на другой функции.

Но не делайте это довольно часто. Я вижу одного разработчика, который сделал это, и неделю или две он выбрасывает 10 PR для слияния. Это было совершенно утомительно для других участников для обзора и трудно объединить также. Попробуй не превращать деревья в мерзавца. Это помогает разобраться с ошибками.

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

В идеале все ветви возвращаются к той кодовой строке, с которой они были объединены. Обычно это слияние с основной линией (в git-flow это dev). Ветка ветвей объектов и слияние с dev, ветвь релизов и слияние с dev (с дополнительным слиянием master). Исправления веток и слияния от мастера (с этим дополнительным слиянием обратно в dev).

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

Если ветвь из ветви функций - это «Я хочу исследовать этот способ решения проблемы в этой ветви функций» - прекрасно. Он ветвится из ветви функций, фиксирует некоторый код и сливается обратно с веткой функций (или отбрасывается).

1. ответвление от фича
2. изучить идею
3. объединить в функцию

Однако, чего вы хотите избежать, это выглядит так:

1. ответвление от обязательной функции
2. работать над кодом
3. объединить с dev после того, как обязательная функция завершена
4. проверить работоспособность (и дополнительные коммиты) в ветви функций
5. объединить с разработчиком

Причина в том, что начало и конец не совпадают - становится немного сложнее понять, что это такое и что было. Не невозможно, но для того, чтобы кто-то понял свою роль, требуется немного больше времени.

Однако, если это новая функция, которая зависит от кода, который еще не найден в dev, поток должен быть:

1. ветка от разработчика
2. объединить с обязательной функцией
3. работать над кодом
4. объединить с dev после того, как обязательная функция завершена
5. проверить работоспособность (и дополнительные коммиты) в ветви функций
6. объединить с разработчиком

Обратите внимание, что это начинается с ветки от dev и заканчивается слиянием с dev.

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

1. ветка от разработчика
2. работать над кодом
3. объединить с dev после того, как обязательная функция завершена
4. проверить работоспособность (и дополнительные коммиты) в ветви функций
5. объединить с разработчиком

Это обеспечивает наиболее стабильный набор веток и кода.

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

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

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

Тем не менее, нет строгого правила против этого. В конце концов, это всего лишь шаблоны и лучшие практики.

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

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