Игнорировать определенные изменения в файле в git, но не весь файл

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

Если этот параметр не затрагивается, кроме этого изменения, git add . никогда не должен ставить его.
Аналогично, git commit -a не должен его фиксировать.
Если я когда-либо сделаю дополнительные изменения в файле, я смогу выполнить и зафиксировать это изменение, но изменение, которое я игнорирую, не должно быть организовано и зафиксировано.

Есть ли способ сделать это? Проводя некоторые исследования, я читал о "часах размытия/чистки", где, если я правильно прочитал,

файл будет помечен как неизменный,
изменение, которое я сделал, будет перезаписано при оформлении заказа,
а затем script автоматически заменит изменение, а затем снова пометит файл как неизменный.

Я очень новичок в git и сценариях (хотя я стажер с опытом работы на С# и Java), поэтому, если это то, что мне нужно сделать, можете ли вы отправить подробные инструкции или ссылку на учебник по как установить цикл смазывания/очистки вверх?

Фон: Я хочу, чтобы моя рабочая ветка не синхронизировалась с багажником. Существует ошибка с низким приоритетом, которая влияет только на машины разработки, поэтому вместо исправления мы просто комментируем код нарушения. Очевидно, что мы не хотим, чтобы этот код был удален из производства, где он работает очень хорошо.

Ответ 1

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

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

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

git checkout -b new-branch
# now you can change the file without affecting master
echo bar >> foo
git add
git commit
# and back to master
git checkout master

Ответ 2

Вы можете использовать бит skip-worktree. Включите его:

git update-index --skip-worktree <file>

После этого git никогда не будет сгенерировать изменения для <file> и не сработает (громко), если ему нужно записать на <file> (например, в слиянии или выписке).

Если вы когда-либо захотите провести новое изменение, вы можете отключить его, сменить новое изменение и снова включить его:

git update-index --no-skip-worktree <file>
git add -p <file>
git update-index --skip-worktree <file>

Это не идеально, поскольку вы не будете уведомлены о каких-либо изменениях в <file>, но это может быть обходным путем.

Примечание. Мое первоначальное предложение состояло в том, чтобы использовать take-unchanged. Как объяснено в Git - разница между "предполагать-неизменным" и "skip-worktree" , вы действительно хотите работать с skip-worktree.

Ответ 3

Git "режим исправления" идеально подходит для добавления только определенных изменений из файла в ваш фиксатор.

Чтобы запустить его, введите git add -p, git commit -p (прямо для фиксации сообщения по завершении) или git add --interactive (дополнительные подсказки).

По сути, он проходит через каждый раздел кода, показанный в git diff, и спрашивает, хотите ли вы его выполнить или нет.

Когда вы достигнете изменения, ответьте n o или e, чтобы открыть патч в $EDITOR.

Ответ 4

Да, это, вероятно, можно было бы сделать, используя фильтры smudge/clean. Однако я бы настоятельно советовал не делать этого, потому что он был бы довольно сложным и подверженным ошибкам (например, это сбивало бы с толку многие инструменты, основанные на git, это затрудняло бы отладки и т.д.).

Кроме того, обычно не рекомендуется иметь постоянные локальные изменения. Одним из важных моментов использования SCM является то, что вы можете проверить версию и немедленно ее запустить. Это означает, что все, что вам нужно, должно быть проверено.

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

Проблема заключается в том, что у вас есть файл со смешанным контентом: некоторый контент, который всегда один и тот же, который нужно изменить локально (параметры, специфичные для машины?). Рекомендуемый способ справиться с этим - не проверять проблемный файл, а вместо этого проверять файл "шаблон", а затем генерировать реальный файл во время сборки. Попытайтесь исследовать это. Сейчас будет больше работы (возможно), но упростит ситуацию, особенно если вам нужно поддерживать больше вариантов или если другие люди хотят работать над одним и тем же проектом.

Изменить (на основе информации в комментарии)

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

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

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

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

(1) В качестве примера: В нашей компании у нас есть переменная среды, специально для таких случаев. Он указывает, работает ли код в процессе разработки, в бета-тестировании или в производстве, и устанавливается нашими сценариями сборки и развертывания. Однако он обычно используется только для простых вещей, таких как выбор разных путей к файлам. Изменение логики программы на основе среды обескураживается, как объяснялось выше.

Ответ 5

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

Вот способ, который мне нравится:

Внесите некоторые изменения, которые вы хотите сохранить на своей локальной машине.
Используйте git branch local и git checkout local, чтобы создать новую ветку для локальных изменений. (Если я не ошибаюсь, эти команды не будут настраивать удаленную ветвь автоматически, поэтому новая ветвь не будет нажата.)
Используйте git commit для фиксации изменений.
Внесите изменения, которые вы хотите нажать вверх по течению.
Используйте git checkout parent, чтобы вернуться к ветке, которую вы хотите нажать.
Используйте git commit для фиксации этой ветки.
Используйте git push, чтобы внести изменения.
Используйте git checkout local, чтобы вернуться в локальную ветвь.
Используйте git rebase parent, чтобы внести изменения с parent в local. Использование rebase приведет к тому, что ваши локальные изменения останутся в верхней части изменений в parent.
Вернитесь к шагу 4 и повторите рекламный тошноту.

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

Ответ 6

Если вы не можете использовать .gitignore, как вам нужно сделать параллельные изменения в том же файле (как указано в ваших комментариях), тогда один параметр - git add -p. Используя это, вы можете добавить или пропустить соответственно.

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

Ответ 7

Как и в случае Git 2.5 (июль 2015 г.), вы можете использовать git worktree:

git worktree add -b patch-1 ../patch-1

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