Как вы легко можете удалить ветку темы в Subversion / git? - PullRequest
Новая
       32

Как вы легко можете удалить ветку темы в Subversion / git?

9 голосов
/ 12 июля 2011

Итак, у меня есть /trunk, которому в конечном итоге привержены все золотые вещи. И у меня есть ветка темы, /topicA.

Обычно вы сливаете /topicA в транк, и это будет один коммит. Ура! Чтобы отменить это слияние, вы просто должны отменить слияние, вызванное этим слиянием. Легкий горох.

Теперь, допустим, у меня есть /topicA, и я объединяю его с /trunk ... Но тогда у меня есть исправление, относящееся к /topicA. Итак, я должен снова совершить /topicA? Я могу даже вспомнить /topicA, чтобы /trunk содержал /topicA. Но как мне легко откатить все /topicA, оригинальную работу и исправления ошибок?

История коммитов:

  • Подтвердить /topicA
  • Подтвердить /topicA
  • Подтвердить /topicA
  • ...
  • Слияние /topicA в /trunk
  • ...
  • Исправлено1 до /topicA
  • Повторно /topicA в /trunk для исправлений
  • ...
  • Исправление2 до /topicA
  • Bugfix3 до /topicA
  • Снова /topicA в /trunk для исправлений
  • ...

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

Есть ли у git ответ на этот вопрос?

Ответы [ 6 ]

2 голосов
/ 23 июля 2011

Вы можете переписать историю, используя 

git rebase --interactive --preserve-merges <hash before first merge>

Это вызовет ваш текстовый редактор по умолчанию со списком коммитов, включая ваши слияния.Удалите все слияния из списка, который появляется в редакторе и сохраните, затем выйдите.git будет воспроизводить все коммиты, кроме тех, которые вы удалили, переписывая историю.Ваша ветка / topicA будет по-прежнему существовать, поэтому вы можете просто слить ее в грузовик.

Помогает, чтобы во всех слияниях в интерактивном редакторе были слова "Merge ветки", поэтому их легко определить.*

Вот пример текста в редакторе, который скупается после того, как команда выдается в вымышленном хранилище 

pick 07c2942 Added "Hello" to README
pick e98e38b Added "There" to README
pick e3d66ad Added "Here" to README
pick 2105946 Merge branches 'master' and 'tmp'

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

pick 07c2942 Added "Hello" to README
pick e98e38b Added "There" to README

Сохраните и выйдите, и git теперь воспроизведет эти коммиты, за исключением слияния.удалите любую строку, и этот коммит будет удален из хранилища.Также вы можете изменить порядок коммитов в любом порядке.Если у вас есть слияния в середине, вы можете вырезать и вставить их до конца.

1 голос
/ 26 июля 2011

В нашем проекте мы сохраняем еще одну ветвь, пока интеграция не будет завершена (trunk_plus_topicA в вашем случае). Он создан из багажника. Мы сливаем в него коммиты как из ствола, так и из темы А.

Затем, после завершения интеграционных тестов, и мы уверены, что нам нужна тема A, вся topicA_plus_trunk будет объединена в транк (или вы можете заменить транк на trunk_plus_topicA).

В общем случае, когда тема A будет объединена только с транком (или вообще не добавлена), вам не нужна дополнительная ветвь. Вы можете просто объединить коммиты из ствола в тему А. Сделайте исправление ошибок, интеграцию и тестирование в теме A, и в конце объедините все сразу в магистраль.

Как говорит мой друг - «самый простой способ починить сломанную пластину - это не тормозить ее в первую очередь». Этот совет плохо работает в реальной жизни, но довольно часто работает в программной инженерии.

0 голосов
/ 27 июля 2011

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

Это далеко не элегантно, не идеально и не «сексуально», но может быть намного проще, чем одноразовые изменения ветвления по одному, в зависимости от того, сколько работы, не связанной с ветвью, было выполнено в стволе.

0 голосов
/ 24 июля 2011

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

git revert -m 1 <id of second remerge>
git revert -m 1 <id of first remerge>
git revert -m 1 <id of first merge>

Но если вы хотите объединить тему A в какой-то момент после этого, обязательно прочитайте http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt, прежде чем сделать это.

0 голосов
/ 21 июля 2011

К сожалению, вероятно, нет простого ответа на этот вопрос.Это зависит от того, были ли переданы коммиты и, следовательно, являются «общедоступными» для других разработчиков (которые, возможно, затем основали работу над ними). ​​

Если коммиты были переданы, ваше единственное реальное решение - этосделайте кучу возвратов и нажмите их.

В противном случае у вас есть варианты сброса перед первым слиянием, завершите исправления ошибок в теме A, а затем объедините их после того, как все они сделаны (как предложил X-Istence).*

Как правило, наша команда обычно убивает ветку темы, когда она объединяется с нашим эквивалентом «ствола» и выталкивается (мы также проповедуем с помощью сквош-слияний, так что все это происходит за один коммит).Тогда любые исправления просто применяются к самому «транку».Если ветвь темы не должна была приземлиться, мы всегда можем заново сгенерировать ветку темы из коммита и затем отменить слияние.Затем разработчик скрывается, делает больше работы над темой, чтобы сделать ее более стабильной, и пытается объединить ее позже.

0 голосов
/ 12 июля 2011

Если вы не слились с какой-либо другой работой в то же время, вы можете использовать git reset --hard <sha-1>, чтобы вернуть рабочее дерево назад к более старому времени, а затем снова добавить topicA поверх trunk. * 1004. *

...