Как очистить общие коммиты от ветки? - PullRequest
Новая
       14

Как очистить общие коммиты от ветки?

0 голосов
/ 12 октября 2011

У меня есть пара веток, соответствующих заброшенной или отложенной позже разработке, некоторые из них - чистый мусор.Я использую 

git log master..mybranch

, чтобы выяснить, что такое mybranch, но списки, как правило, излишне длинны, поскольку они также содержат коммиты, содержащиеся в master, просто в другом порядке.Это происходит из-за того, что master был перебазирован.

Когда я пытаюсь перебазировать mybranch поверх мастера, я получаю конфликты, вызванные этим переупорядочением.Такие конфликты не стоит разрешать, так как это требует времени и приводит к результату, уже известному из master.

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

Ответы [ 3 ]

4 голосов
/ 12 октября 2011

Я думаю, что вы ищете git cherry. Это генерирует значения sha1 из тела коммита, а не использует git commit id для сравнения коммитов. Это делает его независимым от порядка фиксации. Вы используете его для поиска коммитов, которые, возможно, стоит добавить из одной ветви в другую.

Пример из дерева разработки msysGit может помочь. У нас есть старая ветка 'work / symlink', которая могла быть когда-то слита с веткой 'devel'. Итак: 

pt111992@UKNML4132 /git (devel)
$ git cherry devel origin/work/symlink
+ 7fe3fde1d9b93472faeedb75bfd930825a5abe06
- aebecb0d31e4a546cf4d21d32e82cc852b6057bb
+ 1b467d086fd6601cd2feb34d59baf1e804f70acb
+ 3e735a0bfda6b91ae7cbb20c2c89818405c5bea9
+ d4db723c482ba4d2fd7539060834d231c35cdf53

Это говорит о том, что есть 5 коммитов интереса (которые мы также можем определить из вывода журнала): 

$ git  log --oneline devel..origin/work/symlink
d4db723 Place __stdcall between return value and function name
3e735a0 mingw.c: Use the O_BINARY flag to open files
1b467d0 Test for WIN32 instead of __MINGW32_
aebecb0 Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
7fe3fde Support UTF8<=>Unicode filename mapping

То, что коммиты присутствуют в 'work / symlink', а не в 'devel'. Вывод git cherry предполагает, что коммит aebecb0 уже применен к 'devel' (от ведущего минуса), но другие, возможно, стоит изучить. Мы можем проверить, что этот коммит присутствует только в рабочей ветке: 

$ git branch --all --contains aebecb0
  remotes/origin/work/symlink

но мы также можем найти идентификатор коммита, с которым он слился в ветку devel, с помощью поиска сообщения коммита, используя git log --crep, чтобы увидеть, что это действительно было выбрано в devel.

1 голос
/ 12 октября 2011

Предложил это в комментарии, но чем больше я читаю ваш пост, тем больше я думаю, что вы этого не пробовали:

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

1 голос
/ 12 октября 2011

Если я правильно понимаю, mybranch слил или выбрал вишню ветку master, когда она была активной. Алгоритм слияния Git достаточно умный, если другие коммиты mybranch не связаны с изменениями, произошедшими в собственной разработке master, слияние будет бесконфликтным.

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

Вывод: конфликты не связаны с переупорядочением, о котором вы говорите; сделайте вдох и решите конфликты вручную.

...