Исправление конфликтов слияния при слиянии с одной веткой

Question

У меня есть develop, master и ветвь feature.

Я внес некоторые изменения в ветку feature и сделал PR на master. Я также сделал PR на develop, в котором есть изменения, которых нет в ветви master.

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

Но в основном это было то, что develop было объединено с моей веткой feature, и теперь мой PR на ветке master имеет все эти коммиты из develop ветви.

И мне это не нужно.

Я пытался использовать git revert, но это не помогло моей ветке feature.

Есть ли способ удалить это слияние из ветви feature, или мне просто закрыть этот PR и создать отдельную ветку?

Филиалы выглядят так:

--------------master
  |     |
  |-----|-----------develop
        |------feature

Я слился с master и сделал PR на develop и master из feature филиала.

Не знаю, откуда у меня конфликт, но в ветке develop есть тонны вещей.

Answer 1

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

(Хотя вы используете некоторые термины из gitflow, в gitflow вы не будете объединять функцию напрямую с master. Конечно, вы можете время от времени иметь исправления, которые будут слиться непосредственно с обоими master и develop, но в этом случае вы, вероятно, вначале слились бы с master, зная, что (a) это то место, откуда была разделена ветвь исправления, и (b) все в master уже находится в develop. )

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

Так что, если я понимаю, у вас было

 A -- M <--(master)
     /   
... B -- C -- D <--(develop)

... E -- F <--(feature)

и вы создали PR для интеграции feature в develop, но были конфликты - и чтобы разрешить эти конфликты, допуская проверку до обновления develop, процесс разрешения объединится в feature

 A -- M <--(master)
     /   
... B -- C -- D <--(develop)
               \
  ... E -- F -- X <--(feature)

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

В этом случае самый простой путь вперед - это создать новую ветку в F для PR в master.

git checkout feature^
git branch feature_b