#c# #git #coding-style #merge-conflict-resolution
#c# #git #стиль кодирования #слияние-разрешение конфликтов
Вопрос:
Git умен и будет «отслеживать» изменения в истории, чтобы упростить слияние и сделать автоматическое слияние более удобным для меня. Конфликты обозначаются линиями, которые не изменились вокруг изменения. С K amp; R вы не получаете неоднозначных строк, в которых есть только «{«, как в B amp; D. Как бы я проверил предел чувствительности Git к контексту с точки зрения строк, окружающих изменение?
Я хочу избежать разрешения конфликтов, которые мне могут не понадобиться. Но мне нужен какой-то способ проверить, сколько потенциальных конфликтов я сэкономлю, переключившись на K amp; R и дополнительный контекст, который это приносит.
Пока что Git слишком умен, чтобы быть обманутым тривиальными примерами.
Любая помощь приветствуется. Заранее спасибо.
Комментарии:
1. Я прибегну к просмотру исходного кода для git.
Ответ №1:
Итак, это самое близкое, что я нашел на данный момент в качестве доказательства этого.
http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html
В электронном письме обсуждается назначение алгоритма «терпения» в Git. В нем Брэм объясняет, как лишние совпадающие строки могут создавать неприятные конфликты, которые может быть трудно разрешить, но только в случае довольно сложных слияний, включающих большие исправления. Другими словами, простые надуманные примеры не смогут показать это поведение.
Хотя он также упоминает такие вещи, как End, влияющие на результаты, имеет некоторый смысл сделать вывод, что размещение открывающей фигурной скобки в своей собственной строке увеличивает количество лишних совпадающих строк, что, возможно, приводит к большей вероятности этих конфликтов.
Я бы сказал, что это не железно, но это придает некоторую убедительность этой теории.
Итак, «уникальные строки» — это простой межъязыковой прокси для «неважных строк».
Эта цитата выделяется для меня в этом обсуждении, поскольку мы в основном сопоставляем то, что считаем важными строками, которые должны давать нам контекст, однако скобка сама по себе не важна и не предоставляет контекста.
Ответ №2:
Выберите стандарт, который вам / вашей команде будет легче читать поверх всего остального. Независимо от того, как ваша система управления версиями ведет себя сегодня, завтра она будет вести себя лучше, но ваш код останется таким, каким вы его проверили в течение длительного времени.
Комментарии:
1. Вопрос больше о git, а не о том, какой стандарт более удобочитаем. Здесь префикс равен половине (некоторые люди ненавидят прокрутку, так как некоторым нравится лишний пробел), поэтому у меня есть возможность использовать тот, который создает наименьшие трения. Проект mono огромен, и он использует K amp; R. Большинство примеров кода — B amp; D. Я определенно предпочитаю K amp; R. Я не хочу говорить о предпочтениях. Я хочу, чтобы это обеспечивало наименьшее количество трений. Мы делаем ветвление для каждой функции, поэтому происходит МНОГО слияний. Если я смогу минимизировать количество конфликтов, это большой выигрыш в эффективности.
Ответ №3:
У нас есть несколько крупных проектов (более 200 файлов кода), которые содержат огромную смесь как K amp; R, так И B amp; D. Я могу с уверенностью сказать, что после почти 2 лет работы в Git, штат разработчиков, помешанный на рефакторинге, и перебазирования «несколько раз в день», у меня никогда не было конфликта из-за стандартов кодирования. Поэтому выберите любой, или оба, или ни один. Это не будет иметь значения.
Комментарии:
1. Я неохотно принимаю это как ответ. Но я сделаю репост, когда у меня будут точные шаги, необходимые для воспроизведения проблемы.