Я не думаю, что коммит 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 ). Специальная обработка, требуемая для вашего файла конфигурации, будет просто еще одним шагом, который нужно выполнить при восстановлении после перезаписи:
- Сохраните копию файла конфигурации.
- Восстановить от переписать.
- Восстановите файл конфигурации.
Проигнорируйте это, чтобы предотвратить повторение
Какой бы метод вы ни использовали, вы, вероятно, захотите включить имя файла конфигурации в .gitignoreфайл в хранилище, чтобы никто не мог случайно по ошибке git add foo.conf(это возможно, но требует -f/ --force). Если у вас есть более одного файла конфигурации, вы можете подумать о «перемещении» их всех в один каталог и игнорировании всего этого (под «перемещением» я имею в виду изменение того, где программа ожидает найти свои файлы конфигурации, и получение пользователей (или механизм запуска / развертывания) для копирования / перемещения файлов в новое место; очевидно, вы не захотите помещать файл в каталог, который вы будете игнорировать).