Как найти в истории Git-репозитория ошибку слияния? - PullRequest
8 голосов
/ 17 февраля 2009

В какой-то момент в наших прошлых ветках разработки в git были объединены. Однако было принято неправильное решение о слиянии, и поэтому некоторый код не попал в основную ветку, которая, как мы ожидали, будет там. (Перед окончательным слиянием с основной ветвью было несколько слияний разных ветвей. Поэтому история ветвления и слияния была довольно сложной.)

Есть ли простой способ поиска в git-хранилище, чтобы определить, по какому слиянию было принято "неправильное" решение?

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

РЕДАКТИРОВАТЬ: Git обвинение оказалось неадекватным, потому что линия была затронута в коммите после ошибки слияния.

Ответы [ 5 ]

10 голосов
/ 17 февраля 2009

Без дополнительных подробностей я могу только намекнуть на возможные решения. Если вы знаете, какой файл или строка затронуты, вы можете попробовать либо git-blame (git blame *file*, либо git blame *revision* *file*), либо попробовать так называемый ' кирка поиск' с git-log , то есть git log -S'*line* пытается найти ревизию, которая ввела данную строку или удалила данную строку. Вы можете найти и изучить все слияния, например, с помощью git log -p -m --grep=Merge и проверить, как они относятся к своим родителям (-m показать различия для всех родителей; альтернативно -c показывает комбинированный дифференциал, но не показывает тривиальные изменения слияния, т.е. если одна сторона была взята).

9 голосов
/ 12 августа 2011

Журнал Git имеет мощные возможности поиска. Поскольку есть указание на то, что вы знаете часть кода, которая исчезла, вы можете искать эту строку кода

git log <HERE>..<THERE> -S"line I care about" --diff-filter=M

Будет искать от ЗДЕСЬ до ЗДЕСЬ строку после -S и только там, где строка была изменена (добавлена ​​или удалена)

Вы можете добиться еще большей точности в своем поиске, если используете -G вместо -S. -G обеспечивает поиск по регулярному выражению вместо поиска строкового литерала с -S.

9 голосов
/ 17 февраля 2009

Может ли git-bisect помочь в вашем случае?

7 голосов
/ 17 февраля 2009

Если вам известна строка в файле, которая была изменена слиянием ветки git, вы можете выполнить 'git blame file.txt' и определить номер хеша коммита и автора коммита строки в файле. Затем вы можете просмотреть журнал git и получить точную фиксацию, связанную с неудачным слиянием ветки.

EDIT: В ответ на комментарии автора, если вы ищете исчезновение определенной строки, тогда вам может понадобиться git diff в сочетании с grep и бинарным поиском. допустим, у вас есть номера коммитов 0,1,2,3,4,5,6. Вы знаете, что линия существовала в ревизии 0, но исчезла в ревизии 6. Используйте «git diff» плюс grep для поиска исчезновения.

git diff 0 6 | grep '- line I care about'

На первой итерации вы увидите строку, которая вам не нужна. Затем вы разрезаете номер ревизии пополам и попробуйте снова

git diff 0 3 | grep '- line I care about'

Если grep по-прежнему показывает исчезновение строки (со знаком '-'), то вы знаете, что строка исчезла в ревизии от 0 до 3. Если grep не показывает исчезновение строки, затем линия исчезла в редакциях 4-6.

Продолжайте разрезать ревизии пополам, пока не найдете виновника.

0 голосов
/ 18 января 2011

Для тех, кто ищет более простое решение, запустите gitk (или из Git GUI перейдите в Repository> Visualize X History) и используйте его инструмент поиска.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...