Узнайте, какой пользователь неправильно разрешает конфликты слияния?
У нас часто возникают проблемы с пользователями, которые "неправильно" исправляют конфликты git merge и ломают вещи.
Я скучаю по любому git log параметры, которые я могу использовать, чтобы найти недавние слияния, которые имели конфликты, и которые пользователь git разрешил указанные конфликты.
В некоторых случаях это когда кто-то сливает мастера в ветку "тест", поэтому он может содержать много людей.
Процедура:-
- Сделайте некоторую работу в ветви функций, основанной на master.
- Объединить функциональную ветвь с тестовой веткой для тестирования.
- Мастер будет время от времени объединяться с тестовой веткой, чтобы держать вещи в актуальном состоянии.
Рабочий процесс git нужно значительно улучшить и сделать более строгим, но могу ли я что-нибудь сделать за короткий срок, чтобы найти пользователя, неправильно исправляющего конфликты слияния?
1 ответ
С одной стороны, это действительно тривиально. По-другому, это очень сложно.
Вот как это тривиально:
- Есть слияние. Слияние либо сделано правильно, либо сделано неправильно. Посмотрите на слияние и посмотрите, было ли это правильно или неправильно. В случае ошибки автор и коммиттер сообщают вам, кто это сделал (если вы доверяете автору и коммиттеру 1).
Вот как это очень сложно:
- Есть слияние. Это правильно?
Не существует автоматического способа найти ответ на этот вопрос.
Если у вас есть хорошие автоматизированные тесты, вы можете максимально приблизиться к автоматическому ответу на вопрос. Хорошие автоматизированные тесты не легки, и становятся очень трудными, если вы пытаетесь сделать их очень хорошими.
Если у вас нет автоматических тестов, но есть люди, которые умеют правильно выполнять слияния, вы можете сделать выборочные проверки: просто попросите этих хороших людей повторить слияние самостоятельно и сравнить свой результат с более ранним результатом. Если это то же самое, исходное слияние было сделано правильно. Если это не так, то не было.
Наличие или отсутствие конфликтов слияния не является верным показателем того, было ли слияние выполнено правильно. Git не имеет секретных знаний: он просто комбинирует текст в соответствии с фиксированным набором правил. Тем не менее, если вы хотите выбрать для ручного тестирования, в частности, те слияния, в которых возникли конфликты, вы можете автоматизировать эту часть. Просто повторите объединение (убедившись, git rerere не включен) и посмотреть, есть ли конфликты.
Повторение слияния
Выше фраза "повторить слияние" появляется дважды. Вы можете удивиться, как вы можете повторить слияние. Это в основном тривиально. 2 Сначала найдите идентификатор каждого слияния:
git rev-list --merges <start-point> [additional options if desired]
Это создает список идентификаторов кандидатов. (Вы захотите сохранить их все где-нибудь и указать, какие из них вы проверили, чтобы вам не приходилось перепроверять их позже. Используйте любое специальное решение, которое вам понравится.)
Затем, учитывая идентификатор слияния, просто извлеките его первого родителя в качестве отдельного HEAD и выполните git merge на оставшихся родительских идентификаторах (этот бит зависит от поведения и синтаксиса оболочки POSIX):
id=c79a113... # or whatever, from your list
set -- $(git rev-parse ${id}^@)
git checkout $1 # check out first parent
shift # now that we have $1 out, discard $1
git merge $* # (attempt to) merge the remaining commits
rev^@ обозначение от gitrevisions и означает "все родители данной ревизии". Если все ваши слияния являются стандартными слияниями с двумя родителями, вы можете использовать более понятное (но менее общее):
git checkout ${id}^1
git merge ${id}^2
(gitrevisions синтаксис и оболочка set а также shift Техника учитывает слияния осьминога).
Поскольку это слияние выполняется на отдельном HEAD, результирующее слияние, если оно завершается автоматически, может быть тривиально отменено путем проверки любого другого коммита или имени ветви. Если git merge терпит неудачу с конфликтом, у вас есть конфликтующее слияние с обычными результатами в индексе; Вы можете продолжить слияние или использовать git merge --abort прекратить это. (Статус выхода из git merge будет 0 если слияние будет успешным и ненулевое, если нет.)
1 Помните, что, за исключением передачи коммитов через push или fetch, каждая операция Git выполняется локально кем-то, кто полностью контролирует свой собственный репозиторий. Пользователь, конечно, может лгать и утверждать, что он кто-то другой. Если вы контролируете это вообще, вы можете и должны делать это на границе передачи: когда вы берете коммит у кого-то другого - будь то путем git fetch с вашего конца, или git push с их стороны - вы знаете, с кем разговариваете (с помощью любой аутентификации, которую вы установили: это полностью за пределами Git и обычно из ssh или https в наши дни, часто заключено в сторонние расширения, такие как Gitolite, или предоставляется как сервис чем-то вроде GitHub). В настоящее время у вас есть возможность сделать любую проверку, какую пожелаете, прежде чем принимать коммиты.
Кроме того, вы можете проверить "по факту", используя, например, подписи PGP. Если у кого-то есть подписанные PGP некоторые теги и / или некоторые коммиты, и вы можете проверить эти подписи, вы можете верить, что эти теги и / или фиксации принадлежат им. Затем вы можете распространить это доверие (в той степени, в которой вы готовы, конечно, на основе безопасности SHA-1 и того, насколько вы доверяете подписавшему) на предков этих коммитов и / или тегов, начиная с создания объекта, который соответствует предопределенный SHA-1 и его текст, по крайней мере, очень сложный. (Это называется вторым сопротивлением перед изображением; см., Например, https://crypto.stackexchange.com/q/20997.)
2 Я говорю "в основном тривиально", потому что параметры, предоставленные пользователю git merge не доступны здесь. Вы можете требовать от пользователей, которые используют нестандартные параметры слияния, записывать их в своих коммитах или в примечаниях, прикрепленных к коммитам, но это трудно осуществить. См. Также сноску 1: вы можете применять правила исполнения только на границе передачи.