2017-02-16 20 views
0

У нас есть филиал master и многие ветви короткой жизни, которые сливаются в master после того, как клиенты приняли изменения.Как восстановить длинную ветку git для управления?

В дополнение к этому у нас есть длинные ветви живой среды для системы принятия пользователей и системы производства, названные stage и prod, которые изначально разветвлены от мастера.

Наш рабочий процесс выглядит следующим образом:

  • развивать функцию на художественном отделении
  • функция слияния филиал в stage
  • ждут принятия клиента
  • о принятии сливаться в master
  • master получает слиты на prod на следующий день

Прием от клиента может занять очень короткое время, поэтому на stage есть несколько «функций», которые либо ждут, либо сданы. Потому что, если клиент делает не принять изменения, мы не объединить функцию master, но, к сожалению, она живет на stage как зомби :)

Теперь вопрос (ы):

Как мы сбросили филиал stage в текущий master, не теряя возможность объединить ветки функций, которые все еще ожидают принятия до stage? Цель здесь - избавиться от заброшенных «особенностей».

Возможно ли это без изменения истории и принудительного толчка?

+0

Чтобы уточнить: мы можем, конечно, переписать историю и принудительное нажатие, если нет другого варианта. – migg

+0

В истории есть много коммитов и слияний. Слияние происходит, кажется, проблема, которая предотвращает 'git revert master^.. stage'. – migg

+0

У вас есть ответ, который поможет вам решить проблему? Если да, отметьте это. И это поможет другим, у кого есть подобные вопросы. –

ответ

0

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

Таким образом, мы объединили некоторые ветви, которые, как мы знаем, в настоящее время ожидают возврата клиента до stage и избавились от всех оставленных функций.

1

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

+0

Да, это возможность. Но проблема в том, что существует много много слияний, и это займет много времени, чтобы разобраться в этом. Его два года работы более 20 человек ... надеялись на более легкое решение :) – migg

+0

Ах, этого довольно много, чтобы вернуться. Я думаю, что это может быть то, что вы ищете тогда: https://stackoverflow.com/questions/29768207/revert-all-branch-specific-changes-so-the-branch-reflect-master – Stout01

+0

У меня будет Посмотрите, большое спасибо! Похоже, это будет, если он работает :) – migg

1

Если вы объедините функции в stage с истинными слияниями, легко свернуть эти слияния. Просто запустите git revert на предмет слияния с соответствующим аргументом -m (обычно -m 1).

Если вы объединяете функции в stage путем копирования или быстрой пересылки, это сложнее, так как вы должны отменить каждое фиксацию. Вы можете дать git revert a диапазон коммитов для возврата, и он сделает все из них в соответствующем, например, в первом порядке. Обратите внимание, что диапазоны формы A..B означают «все, что доступно от B, за исключением всего, что можно добраться от A», а с A явно доступно из себя, это исключает совершить A. Следовательно, 1234567..fedcba9 включает в себя фиксацию fedcba9 и ранее возвращается к 1234567, но исключает 1234567.

Если объединить функции в stage с помощью git merge --squash, это копирует все коммиты в один большой (но независимый) совершала, так что вы снова просто запустить git revert на одном скопированной совершить (без -m как это не слияние совершить).

(Обратите внимание, что как бы вы вернуть их, если вы в конце концов обнаружить, что вы хотите, чтобы функция в конце концов, это немного больно.)

+0

Спасибо за это, я попробую, как только смогу. – migg

1

Поскольку все утвержденные функции сливаются в мастер, так что первый неслитый совершить на сцене заброшенная функция. Предположим, что F1, F2 и F3 - это живые объекты, ожидающие принятия клиентов на сцене. И F1 - это заброшенная функция, а F2, F3 - функции приема. Поэтому ему нужно избавиться от F1 на сцене.

  C-----…-----D---F1---F2---F3 stage 
     /   \ 
A---…---B---…---E---…---G  master 
       \  \ 
       F----…----H prod 

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

git checkout stage 
git rebase --onto <commit id for D> <commit id for F1> stage 

то структура будет выглядеть следующим образом:

  C-----…-----D ---F2’---F3’ stage 
     /   \ 
A---…---B---…---E---…---G  master 
       \  \ 
       F----…----H prod 
+0

Спасибо за это, я попробую, как только смогу. – migg

+0

Я пробовал это, и он работает, но есть (были) слишком много объединенных ветвей. – migg