У нас есть проект с примерно 500 000 строк кода, который управляется с помощью git, большая часть из которых - несколько лет. Мы собираемся внести ряд изменений, чтобы привести старый код в соответствие с существующими стандартами сообщества и лучшими практиками в отношении соглашений об именах, обработке исключений, отступов и т.д.
Вы можете думать об этом как о чем-то между красивой печатью и низким уровнем/механическим рефакторингом.
Этот процесс, вероятно, затронет почти каждую строку кода в базе кода (~ 85%), а некоторые строки будут подвержены целым пяти модификациям. Все изменения должны быть семантически нейтральными.
Есть ли способ сделать изменения прозрачными для git вины и т.д., чтобы при просмотре кода через месяц мы увидели фиксацию логики, а не та, в которой отступ или капитализация была изменена? Какой лучший способ вытащить сливки из вилок, которые не прошли этот процесс? Мой нынешний план состоял бы в том, чтобы клонировать script разветвленное репо, применять автоматизированный процесс к нему и его базе, различать их, а затем применять diff. Но я хотел бы получить более чистый ответ. Есть ли какие-либо другие проблемы такого типа, которые я не вижу, и если да, то что можно сделать для их смягчения? Я полагаю, что git bisect и т.д. Должны быть в порядке, git log и т.д., Пересекая большой разрыв, будет раздражать, если вы не будете осторожны, а git diff будет безнадежным, но я не уверен Я не пропущу другую точку боли.
Я не знаю, как лучше всего справляться с некоторыми более инвазивными изменениями, которые вы описываете, но...
Параметр -w для git blame, git diff и других вызывает git игнорировать изменения в пробеле, поэтому вы можете более легко увидеть реальные различия.
Я бы рекомендовал делать эти эволюции один шаг за раз в центральном репозитории Git (как в "общедоступной ссылке" для всех остальных репозиториев):
Но не "отступ-переупорядочение-переименование -...- один гигант совершает".
Таким образом, вы даете Git разумную возможность следить за изменениями в модификациях рефакторинга.
Кроме того, я бы не принял никакого нового слияния (вытащил из другого репо), который не применял тот же рефакторинг, прежде чем нажимать свой код.
Если применение процесса форматирования приводит к любым изменениям в извлеченном коде, вы можете отклонить его и попросить удаленное репо сначала соответствовать новым стандартам (по крайней мере, вытащив из своего репо, прежде чем делать больше нажатий).
Вам также понадобится mergetool, позволяющий агрессивно игнорировать пробелы. p4merge делает это и свободно загружается.
В этом question есть хорошее решение. Вкратце используйте git filter-branch.
Я использовал для себя этот код:
git filter-branch --tree-filter "git diff-tree --name-only --diff-filter=AM -r --no-commit-id \$GIT_COMMIT | grep '.*cpp\|.*h' | xargs ./emacs-script" HEAD
Какой ./emacs-script является script, я написал, используя emacs, чтобы изменить стиль кода, просто просто вызывается indent-region для каждого файла.
Этот код отлично работает, если нет файлов, удаленных или удаленных из репозитория. В этой ситуации использование --ignore-unmatch может оказаться полезным, но я не уверен.