Как сделать Git игнорировать пробелы и вкладки?

У меня есть небольшой проект сценариев, который состоит из пяти разных исходных файлов в одном каталоге под названием "Droid XX-XX-XX". Каждый раз, когда я создавал новую резервную копию исходного каталога, я помещал дату в X. Таким образом, существует около 15 различных версий из разных дат. Я хочу добавить каждый из них в мой новый новый репозиторий Git, начиная с самого раннего.

Однако я столкнулся с несколькими проблемами.

  • Одна из проблем заключается в том, что некоторые из файлов используют вкладки для отступов, в то время как другие используют пробелы, но Git рассматривает целую строку как отличную, даже когда единственная разница - проблема с вкладкой или пробелом. Как я могу сделать Git игнорировать форматирование отступа?

  • Другая проблема заключается в том, что некоторые имена файлов не имеют пробелов, в то время как другие имеют пробелы между словами, но Git рассматривает их как разные файлы. Хуже того, иногда имя файла было изменено на нечто другое (например, "PatrolPlan" было изменено только на "Patrol" ) по какой-либо причине. Когда я добавляю новый набор файлов, как я могу сказать Git, что, хотя имя файла отличается, это действительно просто новая версия определенного более старого файла? Или еще лучше, могу ли я установить его для автоматического определения, когда это произойдет?

  • Последняя проблема заключается в том, что в определенные моменты во время разработки мы объединили два исходных файла в один или разделили на два, но Git не автоматически обнаруживает сходства и выводит то, что произошло. Как я могу сказать Git, что произошло? Или еще лучше, как я могу настроить его на автоматическое обнаружение, когда два исходных файла были объединены или когда один был разделен?

Я понимаю, что вопросы (2) и (3) очень взаимосвязаны. Спасибо за любую помощь!

Ответы

Ответ 1

Похоже, вам нужно больше контролировать и стандартизировать процесс разработки. Тот, кто совершает изменения, должен быть тем же человеком, который модифицирует файлы. Или, по крайней мере, коммиттер должен точно знать, что изменилось.

Внимательно проверьте вывод git diff и используйте флаг -w, чтобы игнорировать пробелы. Существуют также варианты отображения различий внутри строки. См. Раздел "Диффы" в строке ниже.

Обратите внимание, что вы не сможете сообщить git, чтобы пропустить изменения пространства при совершении. Я предлагаю использовать GitX (я предпочитаю вилку "брата" ), которая позволяет вам интерактивно отбрасывать куски перед фиксацией.

Использовать описательные сообщения при совершении. Например, если файл был разделен, скажите так. Сделайте свои коммиты маленькими. Если вы обнаружите, что пишете сообщения с длинными сообщениями, разбейте фиксацию на более мелкие части. Таким образом, когда вы будете изучать журналы долгое время, будет более понятным, что изменилось.

Разница в пределах строки

Git имеет некоторую способность показывать "слово" различия в одной строке. Самый простой способ - просто использовать git diff --color-words.

Однако мне нравится настраивать значение слова, используя конфигурацию diff.wordRegex. Мне также нравится формат plain word-diff, потому что он более четко показывает, где различия (вставляет скобки вокруг изменений в дополнение к использованию цвета).

Команда:

git diff --word-diff=plain

вместе с этим в моей конфигурации:

[diff]
        wordRegex = [[:alnum:]_]+|[^[:alnum:]_[:space:]]+

Это регулярное выражение рассматривает их как "слова":

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

У вас должна быть последняя версия git для использования wordRegex. См. Справочную страницу git-config, чтобы узнать, указан ли этот параметр.

UPDATE

Если вы используете git mv для переименования файла (который предпочтительнее использовать другой инструмент или ОС для переименования), вы можете увидеть git обнаружение переименования. Я настоятельно рекомендую переименовать независимо от каких-либо изменений в содержимом файла. Это потому, что git фактически не сохраняет тот факт, что вы переименовали - он использует эвристику в зависимости от того, насколько файл изменился, чтобы угадать, был ли он одним и тем же файлом. Чем меньше вы меняете его во время переименования, тем лучше.

Если вы немного изменили содержимое файла, вы можете использовать -C param для git diff и git log, чтобы попытаться обнаружить копии и переименовать. Добавьте процент (например, -C75%), чтобы сделать git более мягким в отношении различий. Процент представляет собой то, как подобное содержимое должно считаться совпадением.

Ответ 2

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

  • Было бы лучше сделать глобальную замену поиска с помощью регулярного выражения, чтобы стандартизировать пробел между всеми файлами в разных версиях проекта, так что когда они будут последовательно зафиксированы, изменения в пробелах не понадобятся совершает. При этом инструмент Atlassian SourceTree diff позволяет скрывать изменения пробелов, поэтому, по крайней мере, вы их не увидите.

  • Ключом, связанным с изменениями имен файлов, является фиксация, в которой изменяется только имя файла (не изменяйте никаких других изменений). Затем сделайте фиксацию, где изменяется ее содержимое. Таким образом, обычные инструменты разграничения, которые не выполняют тонны эвристики и глубокого рытья, могут иметь смысл из того, что произошло. Проблема в том, что если слишком много изменений в файле, как и имя И много содержимого, то большинство инструментов diff будут рассматривать его как сводное удаление и новый файл. (как указано в правильном ответе)

  • Это сложнее, там нет действительно хорошего пути. Если вы разделите файл на два или объедините два, это будет просто уродливо в diff. Старайтесь не делать много изменений одновременно с делением, так что разделение будет одним, а последующие изменения будут другими.

Ответ 3

  • Вы не сможете сделать git игнорировать вкладки/пробелы, так как git создает хэш каждого файла, и если хэш отличается, файл считается другим.

  • Git обрабатывает деревья (каталоги) так же, как файлы; если их содержимое изменяется, то это разные деревья.

Я не думаю, что эти изменения ничего не могут волновать; они происходят во время любого развития. Я считаю, что лучший подход для вас - переигровка вашего развития с помощью git. Другими словами, начните с вашей начальной версии, а затем внесите необходимые изменения (как вы это делали изначально), а git запомнит, что вы делаете.

Необязательно. Если вы хотите записать дату/время изменений, чтобы они были примерно такими, которые были первоначально сделаны, вы можете использовать опцию командной строки --date для git commit, чтобы сообщить git, когда эти изменения были сделаны.