Лучший способ заставить Git закрывать глаза на мои изменения

Question

Есть ли какой-нибудь более чистый способ заставить Git просто игнорировать некоторые из моих изменений и никогда не фиксировать их? .gitattributes:

config_to_be_deviated.xml filter=qqq

.git / конфигурация:

[filter "qqq"]
 clean = "perl -ne 'print unless /git_please_dont_look_here/'"
 smudge = (Q=$(mktemp) && cat > $Q && patch -s $Q < /tmp/pp && cat $Q && rm $Q)

Патч / tmp / pp добавляет мои изменения с "git_please_dont_look_here" в каждой строке. Git удаляет все такие строки перед загрузкой файла в хранилище и читает мои изменения при его проверке; Я могу продолжать добавлять и вносить полезные изменения в config_to_be_deviated.xml, но изменения в патче не будут видны Git.

Answer 1

• Поместите каноническую конфигурацию по умолчанию в дерево git, но не играйте с ней в игры. Он находится в дереве, и если вы внесете в него изменения, они будут зафиксированы.
• Программное обеспечение ищет конфигурацию по умолчанию, но также ищет конфигурацию в домашнем каталоге разработчика. Если он находит оба, он объединяет два. Любые элементы конфигурации, найденные в файле конфигурации разработчика, переопределяют элементы в файле конфигурации по умолчанию.

Теперь конфигурация по умолчанию отслеживается, а ваши настройки конфигурации по умолчанию - нет.

Answer 2

Похоже, этот подход "фильтра" подходит мне лучше всего.

Плюсы:

1. Нет необходимости каждый раз использовать пользовательские сценарии или специальные команды. Единовременная настройка.
2. Никаких дополнительных коммитов в истории или в тайнике. Чистые различия и исправления.
3. Низкий уровень совершения неправильной вещи.
4. Относительно легко вносить незначительные отклонения (например, переопределение номера порта в конфигурационном файле), например, простой сценарий sed как для размазывания, так и для очистки.

Минусы:

1. Фильтр программ запускается каждый раз, когда Git читает или записывает файл, это может быть медленным (особенно в Windows).

Answer 3

попробуй git update-index --assume-unchanged --<path>. Он действует как gitignore для файлов, находящихся под контролем исходного кода. Первоначальная цель этой функции состояла в том, чтобы улучшить производительность проверки git-изменений в папке с большим количеством файлов. Вот это doco :

- предположим, без изменений
--no-предположить-без изменений

Когда указаны эти флаги, имена объектов, записанные для пути не обновляются. Вместо этого эти варианты установки и сброса без изменений "бит для путей. Когда бит "предположим, что без изменений" включен, git перестает проверять файлы рабочего дерева для возможных модификаций, так что вы нужно вручную сбросить бит, чтобы сказать мерзавец, когда вы меняете рабочее дерево файл. Это иногда полезно, когда работая с большим проектом на файловая система с очень медленным lstat (2) системный вызов (например, cifs).

Эта опция также может использоваться в качестве грубого механизма на уровне файлов, чтобы игнорировать незафиксированные изменения в отслеживаемых файлах (Сродни тому, что делает .gitignore для неотслеживаемые файлы). Вы должны помнить что явная операция git add все равно приведет к тому, что файл будет обновился с рабочего дерева. Гит потерпит неудачу (изящно) в случае необходимо изменить этот файл в индексе например при слиянии в коммите; Таким образом, если предполагаемый неотслеживаемый файл изменилось вверх по течению, вам нужно будет справиться с ситуацией вручную.

Answer 4

Поместите их в отдельный файл, проигнорируйте файл в git и подключите его к вашей сборке, чтобы он был включен?

Answer 5

Я не всем знаком с Git. В Mercurial я использую очередь исправлений (MQ) или полку (похожую на git stash) для таких вещей.

git stash может быть удобно использовать, если вы «локализуемы», информацию легко найти (например, все в одном файле конфигурации).

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