Должен ли я сделать вишню?

Question

Разработчики предполагают создать ветвь компонента из master, а затем начать кодирование, но вместо этого они создали ветку Feature из ветви разработки, а затем объединяются в ветвь разработки.(не все функции из ветви разработки будут в основной ветви)

Когда я пытаюсь создать PR, чтобы объединить его функциональную ветвь (не разрабатывать) с веткой релиза (ветвь релиза создается из главной ветки)- он показывает коммиты на PR, которые он не зафиксировал, а коммиты показывают из ветки развертки, которой нет в ветке master.почему это случилось?

Разработчик зафиксировал только Task-6 Suspend Post в Task-6-Suspend-Post ветке.

Пример:

https://github.com/superc0der/test/compare/RELEASE/1.5.0...Task-6-Suspend-Post?expand=1

Только Task-6 Suspend Post должно быть объединено в ветке релиза.(https://github.com/superc0der/test/commit/62f68ec3d951bca5b848932df01ea8a29f0f562f)

Нужно ли делать cherry-pick или как решить эту проблему? Есть такая же проблема с несколькими ветками функций.

Answer 1

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

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

Answer 2

Проблема

Операция слияния объединяет две (или более) ветви в один коммит (коммит слияния).Вы имеете следующую ситуацию:

A - B (master)
     \              
      C - D (develop)     
           \     
            E (Task-6-Suspend-Post)

Поскольку ветвь Task-6-Suspend-Post создается из develop, она содержит коммит C и D в своей истории.При выполнении слияния Task-6-Suspend-Post в master следующая история будет выглядеть следующим образом:

A - B --------- G
     \         / 
      C - D   /
           \ /
            E 

Другими словами, PR является требованием для создания коммита слияния для последней на главном (B) и самое позднее Task-6-Suspend-Post (E).Это сделает коммиты C и D доступными через историю мастера и, таким образом, включены в запрос на извлечение.

Решение

Создание перебазирования изTask-6-Suspend-Post решит вашу проблему.

git rebase master Task-6-Suspend-Post

Приведенная выше команда создаст новый коммит E' с тем же содержимым, что и E, но с главой мастера (B) в качестве родителя.Указатель ветвления Task-6-Suspend-Post будет присоединен к новому E' коммиту.

     E' (Task-6-Suspend-Post)
    /
A - B (master)
     \              
      C - D (develop)

При принудительном нажатии нового Task-6-Suspend-Post и создании нового запроса на вытягивание только один коммит должен быть частью PR.

git push origin -f