Я не думаю, что коммит Git может записать намерение типа «прекратить отслеживание этого файла, но не удаляйте его».
Для реализации такого намерения потребуется вмешательство за пределами Git в любых репозиториях, которые объединяют (или перебазируют) коммит, удаляющий файл.
Сохранить копию, применить удаление, восстановить
Вероятно, самое простое, что нужно сделать, - это попросить своих нижестоящих пользователей сохранить копию файла, вытащить удаление, а затем восстановить файл.
Если они вытягивают через rebase и «переносят» изменения в файл, они получат конфликты. Чтобы разрешить такие конфликты, используйте git rm foo.conf && git rebase --continue (если конфликтующий коммит имеет изменения помимо тех, которые внесены в удаленный файл) или git rebase --skip (если конфликтующий коммит был изменен только на удаленный файл).
Восстановить файл как неотслеживаемый после извлечения коммита, который удаляет его
Если они уже извлекли ваш коммит удаления, они все еще могут восстановить предыдущую версию файла с помощью git show :
git show @{1}:foo.conf >foo.conf
Или с git checkout (за комментарий Уильяма Перселла; но не забудьте удалить его из индекса!):
git checkout @{1} -- foo.conf && git rm --cached foo.conf
Если они предприняли другие действия после извлечения вашего удаления (или они вытаскивают с ребазой в отдельную ГОЛОВКУ), им может понадобиться что-то, кроме @{1}. Они могут использовать git log -g, чтобы найти коммит незадолго до того, как извлекут ваше удаление.
В комментарии вы упоминаете, что файл, который вы хотите «отследить, но сохранить», является неким файлом конфигурации, который необходим для запуска программного обеспечения (непосредственно из хранилища).
Сохранить файл как «по умолчанию» и активировать его вручную / автоматически
Если не совсем неприемлемо продолжать поддерживать содержимое файла конфигурации в хранилище, вы можете переименовать отслеживаемый файл из (например) foo.conf в foo.conf.default, а затем дать указание своим пользователям cp foo.conf.default foo.conf после применения переименовать коммит.
Или, если пользователи уже используют какую-либо существующую часть хранилища (например, сценарий или другую программу, сконфигурированную с помощью содержимого в хранилище (например, 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 rebase manpage ).
Специальная обработка, требуемая для вашего файла конфигурации, будет просто еще одним шагом, который необходимо выполнить при восстановлении после перезаписи:
- Сохраните копию файла конфигурации.
- Восстановить после перезаписи.
- Восстановить файл конфигурации.
Игнорировать это, чтобы предотвратить повторение
Какой бы метод вы ни использовали, вы, вероятно, захотите включить имя файла конфигурации в файл .gitignore в хранилище, чтобы никто не мог случайно git add foo.conf снова (это возможно, но требует -f / --force ).
Если у вас есть больше, чемодин файл конфигурации, вы можете подумать о «перемещении» их всех в один каталог и игнорировании всего этого (под «перемещением» я имею в виду изменение того, где программа ожидает найти свои файлы конфигурации, и получение пользователей (или механизм запуска / развертывания) ) скопировать / переместить файлы в их новое расположение; очевидно, вы не захотите git mv файл в каталог, который вы будете игнорировать).