Как вы делаете в Git игнорировать пробелы и знаки табуляции?

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

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

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

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

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

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

15
diff git indentation

3 ответов

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

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

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

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

различия в строку

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

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

: 
git diff --word-diff=plain

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

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

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

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

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

обновление

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

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

22

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

  1. было бы лучше сделать глобальный поиск-заменить с помощью regex для стандартизации пробелов между всеми файлами в разных версиях проекта, так что, когда они последовательно фиксируются, изменения пробелов не будут нуждаться в фиксации. Тем не менее, инструмент Diff Atlassian SourceTree позволяет скрывать изменения пробелов, поэтому, по крайней мере, вы не увидите те.

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

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

3

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

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

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

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

2