Блог

У меня есть 3 ветки: 1. мастер 2. функция аутентификации 3. функция-операции. branch 2 and 3 сделаны из master.

Я работал в функции аутентификации и сделал запрос на слияние. И это все еще находится на рассмотрении. Теперь я хочу работать с функциональными операциями, которые создаются из master. Теперь проблема, поскольку функция аутентификации все еще не объединена, и я хочу, чтобы некоторые функции из нее feature-operation были включены. Итак, что лучше всего сделать, чтобы решить эту блокировку? должен ли я был создать feature-operation эту ветку из функции-auth? хотя я где-то читал, что в идеале все ветки должны быть сделаны из master.

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

Таким образом, вы извлекаете выгоду из всех коммитов / функций feature-auth и можете возобновить работу feature-operation .

 git checkout feature-operation
git rebase feature-auth
git push --force
  

хотя я где-то читал, что в идеале все ветки должны быть сделаны из master.

Это не обязательно.

В вашем случае вы получаете из:

Для:

 m--m--m--m--m  (master)
              / (pending MR)
     fa--fa--fa
               
                fo'--fo'--fo' (feature-operation rebased)
  

OP добавляет:

например, я закончил работу feature-operation и до сих feature-auth пор не принят.
Затем после завершения работы и перед выполнением слияния feature-operation я также должен перебазироваться на master ?

Если feature-operation основано на feature-auth работе, вам придется подождать, пока feature-auth будет объединено, прежде чем (действительно) выполнить перебазирование feature-operation поверх обновленного master .

И:

Значит, я не должен вносить какие-либо изменения feature-operation , пока master не будет обновлен? Или непосредственно перед запросом на слияние?

Пока вы работаете feature-operation , вы можете запускать эту работу в своем удаленном репозитории столько раз, сколько захотите.
После feature-auth слияния с master вы перебазируете свою ветку feature-operation поверх master (после ветки git pull on master ), а git push --force feature-operation затем перебазируете свою ветку и продолжаете работать (или, если вы закончили, сделайте MR)

На мой взгляд, функциональные ветви должны появляться из той же ветви, в которую они будут объединены. Если feature b бы это зависело от feature a , они, вероятно, не должны были быть разными ветвями и разными PR для начала.

Перебазирование feature b на feature a может означать, что ваш PR feature b включает все feature a , что неправильно и несправедливо по отношению к процессу утверждения. Не говоря уже о принудительном нажатии, что является плохим знаком.

На мой взгляд, если feature b feature a вам что-то нужно, вы должны просто выбрать это.

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

Я бы принял диаграмму ветвления @VonC, мастер ветвления на fa, а когда fa будет завершен к вашему удовлетворению, разветвляйте fa на fo. Перебазирование не требуется.

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

Окончательное слияние fo с master будет ближе к master, чем в противном случае, что упрощает этот окончательный обзор для всех заинтересованных сторон.