Как указать git, что изменения являются временными и не должны выполняться?

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

Когда я это делаю, мои полуавтоматические механизмы для поиска незафиксированных изменений и несвязанных ветвей часто обнаруживают ложные срабатывания:

Если я оставляю изменения незавершенными или просто поставленными, то моя контрольная панель script помещает репо как грязную.
Если я передам их как "временные изменения фиксации", они будут помечены как "изменения перед удаленной ветвью"
Если я передам их на новую ветку без удаленного, они будут помечены как "ветвь без удаленного".

Обычно все они необходимы для поиска изменений, которые не были объединены, но это также означает, что каждый способ "скрытия" временных изменений также блокируется.

Обратите внимание, что я не хочу - принимать без изменений, поскольку один и тот же файл часто содержит как временные изменения (которые я не хочу напоминать о) и постоянные изменения (что я делаю) и просмотр Обработка временных изменений (не выполняемых) в Git не содержит предложений, которые касаются всех этих требований.

С Mercurial я рассмотрю использование Mercurial Queues, чтобы приблизиться к тому, что я хочу. Я бы создал патч с моими временными изменениями, а затем, если бы моя утилита анализа обнаружила очередь исправлений, она выскочила бы, выполнив анализ, а затем оттолкнула бы их обратно. Это позволит эффективно удалить только временные изменения, выполнить анализ только тех изменений, которые я не считаю временными, а затем повторно применить эти изменения.

Проблема с любым подходом, который изменяет рабочий каталог, заключается в том, что это повлияет на поведение живой системы - например, наша система регистрации проверяет наличие обновлений для конфигурации ведения журнала каждые 10 секунд или около того.

Итак, как я могу лучше всего показать git, что некоторые изменения являются временными и не должны быть зафиксированы и/или объединены, в то время как другие должны?

Ответ 1

Для каждого из этих файлов вы можете настроить чистый script, который будет отвечать за восстановление исходного содержимого этих файлов, поскольку они были изначально извлечены.
Этот script может просто выполнить git checkout -- afile, чтобы восстановить его содержимое в HEAD (отбрасывая любые локальные изменения).

Восстановление файла с помощью script осуществляется с помощью фильтра фильтра содержимого, используя .gitattributes.

^{(изображение из "Настройка Git - Git Атрибуты" из Pro Git book "))}

Как только вы объявите, что этот драйвер содержимого в локальном Git config, он автоматически, на git commit, восстановит файл.
Или он будет считать файл неизменным на git diff/git status.

См. полный пример в Лучшая практика - Git + Автоматизация сборки - Сохранение конфигураций отдельно.

Ответ 2

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

Если я фиксирую [временные изменения] как "временные изменения фиксации", они помечены как "изменения перед удаленной ветвью"

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

Если бы я делал это с помощью mercurial, я бы использовал Mercurial Queues, чтобы внести незначительные изменения в патч, и вытащить его перед анализом, снова надавив на него.

Git ваш слуга. Вы решаете, что означают коммиты. Зафиксируйте свои изменения и используйте Git, чтобы распределить куски, чтобы они были наиболее полезны для вас, чтобы зафиксировать последовательность [s] и границы. Не допускайте незначительных изменений в совершении "незначительных изменений" или имеете ветвь "незначительных изменений" или что-то, что лучше всего работает. Научите свою проверку, чтобы выявить незначительные изменения.

Из того, что вы здесь указали, один обычный "локальный" ветвь с фиксацией накопления, посвященный изменениям конфигурации, должен делать это, когда вы делаете "значительное" изменение, фиксируете и используете интерактивную или автоматическую перезагрузку для записи изменений позади Подсказка. Сообщите своему контролеру игнорировать что-либо в коннекторе локального ветки; обновить локальную конфигурацию, изменить ее и git commit --amend --no-edit, или, если вы goof и зафиксировать ее отдельно, сверните ее с помощью интерактивной переадресации или эквивалентно просто git reset --soft @~ и выполните сделанный вами -amend -no-edit commit, который вы хотели сделать, Там нет необходимости в специальных средствах, вы получаете полный набор инструментов для любой работы, которую вы делаете. Если коммиты считаются особенно значимыми, поставьте их где-то зарезервированным для коммитов с этим конкретным значением.

Ответ 3

Несколько снимков в темноте, пытаясь прочесть между линиями с вашей конечной целью/прецедентом. Это зависит от того, что вы можете/желаете изменить в своей системе или в полуавтоматической системе "репо".

Измените систему так, чтобы элементы конфигурации, которые вам нужно изменить, имеют как файл конфигурации "главный/по умолчанию", так и неподготовленный файл конфигурации локального/пользовательского. Любые настройки в пользовательской конфигурации переопределяют значения по умолчанию.
- Преимущество: вы можете обновить свои сценарии "repo health", чтобы WARN вы о существующих временных настройках (без каких-либо действий), либо все время, либо через определенное время и т.д.
- Преимущество: не нужно ничего делать в Git.
- Недостаток: никакого отслеживания того, что эти настройки были со временем.
Использовать специальные имена/расширения веток или использовать специальные теги для захвата временных настроек и обновить сценарии "repo health", чтобы игнорировать те ветки/теги (или у вас есть WARN, а не для чего-то?)..
- Пример. Назовите ветки, которые захватывают их чем-то особенным (всегда начинайте с "tempsetting-", заканчивайтесь на ".tmp" и т.д.) или передайте их ветке tmp, а затем пометьте их (опять же, вероятно, с некоторым специальным соглашением об именах).
- Преимущество: ваши временные настройки фиксируются в репо, если это необходимо
- Недостаток: больше для этого - нужно активно управлять больше, чем просто конфигурационный файл или пользовательские настройки и т.д.