Своп ветка сливается в git - PullRequest
       77

Своп ветка сливается в git

2 голосов
/ 02 апреля 2019

Я хочу существенно поменяться ролями двух веток в git-репо, когда дело доходит до слияния.Поскольку существует много потенциальных способов решения моей проблемы, я просто объясню свои обстоятельства, чтобы избежать XY-вопроса:

Я разрабатываю прошивку для устройства, которое прошло несколько аппаратных ревизий, для которых требуетсятонкие различия (в основном разные константы) в прошивке.(Соответствующими) версиями аппаратного обеспечения являются «proto2», «proto3» и «proto4».Первоначальная основная ветка называется master, и в настоящее время она соответствует аппаратной ревизии proto2.В те времена, когда появился «proto3», я создал новую ветку под названием («образно») «proto3».Затем я внес изменения, связанные с новой версией аппаратного обеспечения в ветку «proto3», и продолжил разработку в «master» для ревизии «proto2».Таким образом, я мог бы затем извлечь «proto3», слить в него «master» и получить мою «proto3» -совместимую прошивку с новыми функциями.С тех пор появился «proto4», в котором есть еще одно изменение (буквально однострочное).Итак, теперь я развиваюсь в «master», а затем должен всегда объединять изменения в «proto3» и «proto4» (это также означает, что я должен выполнить разработку на более старом прототипе).

Теперь мыПереходим к производству, и «proto4» будет производственной прошивкой.Однако, так как некоторые из старых прототипов все еще весьма полезны, я бы хотел поменять роли ветвей, то есть иметь возможность развиваться в ветке «proto4» и сливаться оттуда в «master», не вводя связанное с аппаратным обеспечениемизменения, внесенные ранее в «proto4» обратно в «master».

Другими словами, в остальном обычное слияние, за исключением того, что некоторые (старые) коммиты никогда не объединяются из «proto4» в «master».

Я могу придумать пару способов добиться этого:

  1. Я всегда могу просто выбрать новые коммиты из «proto4» в «master».Тем не менее, это нужно помнить, чтобы делать это каждый раз, когда я делаю бэкаппорт изменений, и забывание об этом приводит к путанице.
  2. Я мог бы объединить «proto4» с «master», а затем вернуть все связанное с оборудованиемфиксирует из «proto4» в «master», то есть отменяет изменения.Мне нужно будет покопаться в журнале коммитов, чтобы найти эти изменения, но это должно быть выполнимо.

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

PS: Я, конечно, также собираюсь переименовать ветви, но этоПохоже, что он покрыт Переключение имен веток в git , а может быть, даже лучше https://mohitgoyal.co/2018/04/07/swap-master-branch-with-another-branch-in-git/

Ответы [ 2 ]

0 голосов
/ 03 апреля 2019

Я нашел способ сделать это:

Сначала возьмем различие между текущими заголовками «proto4» и «master»:

git diff proto4..master > diff.txt

Затем объедините «proto4» с «master», то есть теперь «master» - это то, что раньше было «proto4». Шаг первый завершен, включая переименование. Затем создайте новую ветку «proto2» и оформите заказ «proto2». Теперь примените ранее созданный diff:

git apply diff.txt

и зафиксируйте изменения с соответствующим сообщением, т. Е. "Воссозданная прошивка proto2" и т. Д.

Наконец, в качестве шага очистки вы можете удалить ненужную теперь ветку «proto4» (вы можете дважды проверить, что diff master proto4 пуст).

0 голосов
/ 02 апреля 2019

Возможно ли для вас иметь следующее:

  • Рассматривать master как универсальный код,
  • имеет ветвь proto# для каждого оборудования с их конкретными потребностями,все основано на master,
  • при смене мастера, либо перебазируйте ветки прототипа поверх него (это будет означать принудительный толчок и хорошую связь между разработчиками), либо объедините мастер в каждом из них (будетсделать менее чистый журнал и усложнить взгляд на то, что специфично для ветви proto)
  • может иметь производственную прото ветку с именем production-proto#, чтобы быстро узнать, какой продуктone

Таким образом, каждое оборудование может иметь свой собственный код, а master является только общей частью.

Когда вы хотите создать новое оборудование, вы создаете новую ветвь из master.

А если вы хотите прекратить работу оборудования, нужно просто удалить его ветвь.

...