Как обрабатывать распространенные изменения формата кода в git-хранилище - PullRequest
43 голосов
/ 01 декабря 2009

У нас есть проект с 500 000 строк кода, управляемый с помощью git, многим из которых несколько лет. Мы собираемся внести ряд изменений, чтобы привести старый код в соответствие с текущими стандартами и передовой практикой сообщества разработчиков в отношении соглашений об именах, обработки исключений, отступов и т. Д.

Вы можете думать об этом как о чем-то между красивой печатью и низким уровнем / механическим рефакторингом.

Этот процесс, вероятно, затронет почти каждую строку кода в базе кода (~ 85%), и некоторые строки будут подвергаться целым пяти модификациям. Все изменения должны быть семантически нейтральными.

Есть ли способ сделать изменения прозрачными для git обвинений и т. Д., Чтобы при просмотре кода через месяц мы увидели коммит, в котором была введена логика, а не тот, в котором отступ или капитализация был изменен? Какой лучший способ вытащить слияния из вилок, которые не прошли этот процесс? Мой нынешний план состоял бы в том, чтобы сценарий клонировал раздвоенное репо, применил автоматизированный процесс к нему и его базе, изменил их, затем применил diff. Но я бы хотел получить более четкий ответ. Есть ли какие-либо другие проблемы такого рода, которых я не вижу, и если да, что можно сделать, чтобы их смягчить? Я полагаю, что git bisect и т. Д. Должны быть в порядке, git log и т. Д. Пересечение большого пропасти будет раздражать, если вы не будете осторожны, и git diff будет безнадежным, но я не уверен, что я не пропускаю другой болевая точка.

Ответы [ 4 ]

23 голосов
/ 01 декабря 2009

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

Параметр -w для git blame, git diff и другие заставляет git игнорировать изменения в пробелах, чтобы вы могли легче увидеть реальные различия.

11 голосов
/ 01 декабря 2009

Я бы порекомендовал делать эти эволюции по одному шагу за раз в центральном репозитории Git (центральном, как в «публичной ссылке для всех остальных репозиториев»):

  • отступы
  • затем методы переупорядочения
  • затем переименование
  • тогда ...

Но не "отступы-переупорядочивание-переименование -...- один гигантский коммит".

Таким образом, вы даете Git разумную возможность следить за изменениями в модификациях рефакторинга.

Кроме того, я бы не принял никаких новых слияний (извлеченных из других репо), которые не применяли тот же рефакторинг перед отправкой своего кода.
Если применение процесса форматирования вносит какие-либо изменения в извлеченный код, вы можете отклонить его и попросить удаленное репо сначала соответствовать новым стандартам (по крайней мере, потянув из своего репо, прежде чем предпринимать какие-либо дополнительные действия).

9 голосов
/ 01 декабря 2009

Вам также понадобится mergetool, который позволяет агрессивно игнорировать пробелы. p4merge делает это и свободно загружается.

0 голосов
/ 02 октября 2015

Этот вопрос имеет хорошее решение для него. Кратко использовать 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 - это скрипт, который я написал с использованием emacs для изменения стиля кода, он просто вызывает indent-region для каждого файла.

Этот код работает нормально, если нет файлов, которые были удалены или удалены из хранилища. В этой ситуации использование --ignore-unmatch может быть полезным, но я не уверен.

...