Ответ 1
Я не думаю, что коммит Git может записать намерение как "остановить отслеживание этого файла, но не удалять его".
Принятие такого намерения потребует вмешательства вне Git в любых репозиториях, которые объединяют (или переадресуют) коммит, который удаляет файл.
Сохранить копию, применить удаление, восстановить
Наверное, проще всего сказать, чтобы ваши нисходящие пользователи сохраняли копию файла, вытаскивали удаление, а затем восстанавливали файл.
Если они вытягиваются через rebase и "переносят изменения в файл, они получат конфликты. Чтобы разрешить такие конфликты, используйте git rm foo.conf && git rebase --continue (если конфликтная фиксация имеет изменения, кроме изменений в удаленном файле) или git rebase --skip (если конфликтная фиксация только изменилась на удаленный файл).
Восстановить файл как не обработанный после вытягивания фиксации, удаляющей его
Если они уже вытащили фиксацию удаления, они все равно смогут восстановить предыдущую версию файла с помощью git show:
git show @{1}:foo.conf >foo.conf
Или с git checkout (за комментарий William Pursell, но не забудьте удалить его из индекса!):
git checkout @{1} -- foo.conf && git rm --cached foo.conf
Если они предприняли другие действия с момента удаления вашего удаления (или они потянули с перестановкой в отдельный HEAD), им может понадобиться что-то другое, кроме @{1}. Они могли бы использовать git log -g, чтобы найти фиксацию непосредственно перед тем, как они вытащили ваше удаление.
В комментарии вы упомянули, что файл, который вы хотите "не отслеживать, а хранить" - это какой-то файл конфигурации, необходимый для запуска программного обеспечения (непосредственно из репозитория).
Сохранить файл как "По умолчанию и вручную/автоматически активировать его"
Если не полностью неприемлемо продолжать поддерживать содержимое конфигурационного файла в репозитории, вы можете переименовать отслеживаемый файл из (например) foo.conf в foo.conf.default, а затем проинструктировать своих пользователей cp foo.conf.default foo.conf после применения переименования.
Или, если пользователи уже используют некоторую существующую часть репозитория (например, script или какая-либо другая программа, сконфигурированная контентом в репозитории (например, Makefile или аналогичная)) для запуска/развертывания вашего программного обеспечения, вы можете включить дефолтное механизма в процесс запуска/развертывания:
test -f foo.conf || test -f foo.conf.default &&
cp foo.conf.default foo.conf
С таким механизмом дефолта пользователи должны иметь возможность вытащить фиксацию, которая переименовывает foo.conf в foo.conf.default без необходимости выполнять дополнительную работу.
Кроме того, вы не должны вручную копировать файл конфигурации, если в будущем вы создадите дополнительные установки/репозитории.
История переписывания В любом случае требуется ручное вмешательство...
Если недопустимо поддерживать содержимое в репозитории, вы, вероятно, захотите полностью искоренить его из истории с помощью git filter-branch --index-filter …,
Это сводится к перезаписи истории, которая потребует ручного вмешательства для каждого ветки/репозитория (см. Раздел "Восстановление из восходящей базы" в git справочная страница переустановки).
Специальная обработка, необходимая для вашего файла конфигурации, будет всего лишь еще одним шагом, который необходимо выполнить при восстановлении после перезаписи:
- Сохраните копию конфигурационного файла.
- Восстановить из перезаписи.
- Восстановить файл конфигурации.
Игнорировать это, чтобы предотвратить повторение
Какой бы метод вы ни использовали, вы, вероятно, захотите включить имя файла конфигурации в файл .gitignore в репозитории, чтобы никто не мог непреднамеренно git add foo.conf снова (это возможно, но требует -f/--force).
Если у вас более одного файла конфигурации, вы можете подумать о том, чтобы "переместить их все в один каталог и игнорировать все это (" перемещение "означает изменение, где программа ожидает найти свои файлы конфигурации, и получение пользователей (или запуск /deploy ), чтобы скопировать/переместить файлы в новое место, вы, очевидно, не захотите Git mv файл в каталог, который вы будете игнорировать).