Git: jak usunąć plik z indeksu bez usuwania plików z dowolnego repozytorium

Nie sądzę, aby commit Git mógł nagrać intencję typu "przestań śledzić ten plik, ale nie usuwaj go".

Wprowadzenie takiej intencji będzie wymagało interwencji poza Gitem w repozytoriach, które scalają (lub rebase) commit usuwający plik.

Zapisz kopię, Zastosuj usunięcie, Przywróć

Prawdopodobnie najprostszą rzeczą do zrobienia jest powiedzieć dalszym użytkownikom, aby zapisać kopię pliku, wyciągnąć usunięcie, a następnie przywrócić plik. Jeśli ciągną poprzez rebase i "przenoszą" modyfikacje do pliku, dostaną konflikty. Aby rozwiązać takie konflikty, użyj git rm foo.conf && git rebase --continue (Jeśli commit kolidujący z plikiem zmienił się oprócz zmian w usuniętym pliku) lub git rebase --skip (Jeśli commit kolidujący zmienił się tylko w usuniętym pliku).

Przywróć plik jako nie śledzony po wyciągnięciu Commita, który go usunie

Jeśli już wyciągnęli zatwierdzenie usunięcia, nadal mogą odzyskać poprzednią wersję pliku za pomocą git Pokaż:

git show @{1}:foo.conf >foo.conf

Lub z Git checkout (za komentarz Williama Pursella; ale pamiętaj, aby ponownie usunąć go z indeksu!):

git checkout @{1} -- foo.conf && git rm --cached foo.conf

Jeśli podjęli inne działania od momentu wyciągnięcia twojego usunięcia (lub wciągają rebase do odłączonej głowicy), mogą potrzebować czegoś innego niż @{1}. Mogą użyć git log -g, aby znaleźć commit tuż przed usunięciem.

W komentarzu wspominasz, że plik, który chcesz "untrack, but keep" to rodzaj pliku konfiguracyjnego, który jest wymagany do uruchomienia Oprogramowania (bezpośrednio z repozytorium).

Zachowaj plik jako 'domyślny' i aktywuj go ręcznie / automatycznie

Jeśli nie jest całkowicie nie do przyjęcia utrzymanie zawartości pliku konfiguracyjnego w repozytorium, możesz zmienić nazwę śledzonego pliku z (np.) foo.conf na foo.conf.default, a następnie polecić użytkownikom cp foo.conf.default foo.conf po zastosowaniu zmiany nazwy zatwierdzenia. Lub, jeśli użytkownicy skrypt lub inny program skonfigurowany przez zawartość w repozytorium (np. Makefile lub podobny)) do uruchamiania / wdrażania oprogramowania, można włączyć domyślny mechanizm do procesu uruchamiania/wdrażania:

test -f foo.conf || test -f foo.conf.default &&
    cp foo.conf.default foo.conf

Z takim mechanizmem domyślnym, użytkownicy powinni być w stanie wyciągnąć commit, który zmienia nazwę foo.conf na foo.conf.default bez konieczności wykonywania dodatkowej pracy. Ponadto unikniesz konieczności ręcznego kopiowania pliku konfiguracyjnego, jeśli tworzenie dodatkowych instalacji/repozytoriów w przyszłości.

Przepisywanie Historii Wymaga Ręcznej Interwencji W Każdym Razie...

Jeśli utrzymanie zawartości w repozytorium jest niedopuszczalne, prawdopodobnie będziesz chciał całkowicie usunąć ją z historii za pomocą czegoś takiego git filter-branch --index-filter …. Oznacza to przepisywanie historii, które będzie wymagało ręcznej interwencji dla każdej gałęzi / repozytorium (patrz sekcja "recovery From Upstream Rebase" w sekcji Git rebase manpage ). Specjalne traktowanie wymagane dla pliku konfiguracyjnego byłoby kolejnym krokiem, który należy wykonać podczas odzyskiwania po przepisaniu:

1. Zapisz kopię pliku konfiguracyjnego.
2. Odzyskaj po przepisaniu.
3. Przywróć plik konfiguracyjny.

Zignoruj to, aby zapobiec nawrotom

Niezależnie od używanej metody, prawdopodobnie będziesz chciał umieścić nazwę pliku konfiguracyjnego w pliku .gitignore w repozytorium, aby że nikt nie może ponownie (jest to możliwe, ale wymaga -f/--force). Jeśli masz więcej niż jeden plik konfiguracyjny, możesz rozważyć 'przeniesienie' ich wszystkich do jednego katalogu i zignorowanie całości (przez 'przenoszenie' mam na myśli zmianę miejsca, w którym program oczekuje znalezienia swoich plików konfiguracyjnych, i nakłonienie użytkowników (lub mechanizm uruchamiania/wdrażania) do skopiowania / przeniesienia plików do ich nowej lokalizacji; oczywiście nie chciałbyś git mv pliku do katalogu, który ma być będziesz ignorować).