Mam lokalne zmiany w pliku, których nie chcę zatwierdzać w moim repozytorium. Jest to plik konfiguracyjny do budowy aplikacji na serwerze, ale chcę budować lokalnie z różnymi ustawieniami. Oczywiście plik zawsze pojawia się, gdy robię „status git” jako coś, co można inscenizować. Chciałbym ukryć tę konkretną zmianę i jej nie zatwierdzać. Nie wprowadzę żadnych innych zmian w pliku.

Po krótkich poszukiwaniach widzę 2 opcje: „zakładaj bez zmian” i „pomiń”. Poprzednie pytanie tutaj mówi o nich, ale tak naprawdę nie wyjaśnia ich różnic. Moje pytanie brzmi: czym różnią się te dwa polecenia? Dlaczego ktoś miałby korzystać z jednego lub drugiego?

Chcesz skip-worktree.

assume-unchangedjest przeznaczony do przypadków, w których sprawdzenie, czy grupa plików została zmodyfikowana, jest kosztowne; po ustawieniu bitu git(oczywiście) zakłada się, że pliki odpowiadające tej części indeksu nie zostały zmodyfikowane w kopii roboczej. Pozwala to uniknąć bałaganu statpołączeń. Ten bit jest tracony za każdym razem, gdy zmienia się pozycja pliku w indeksie (więc gdy plik jest zmieniany w górę).

skip-worktreeto coś więcej: nawet jeśli git wie, że plik został zmodyfikowany (lub musi zostać zmodyfikowany przez a reset --hardlub podobny), będzie udawał, że tak nie było, używając zamiast tego wersji z indeksu. Trwa to do momentu odrzucenia indeksu.

Istnieje dobre podsumowanie konsekwencji tej różnicy i typowych przypadków użycia tutaj: http://fallengamer.livejournal.com/93321.html .

Z tego artykułu:

• --assume-unchangedzakłada, że ​​programista nie powinien zmieniać pliku. Ta flaga służy do poprawy wydajności niezmienionych folderów, takich jak zestawy SDK.
• --skip-worktreejest przydatny, gdy instruujesz git, aby nie dotykał określonego pliku, ponieważ programiści powinni go zmienić. Na przykład, jeśli w głównym repozytorium nadrzędnym znajdują się niektóre gotowe do produkcji pliki konfiguracyjne i nie chcesz przypadkowo zatwierdzać zmian w tych plikach, --skip-worktreeto dokładnie to, czego chcesz.

Uwaga: fallengamer przeprowadził kilka testów w 2011 roku (więc mogą być nieaktualne), a oto jego ustalenia :

Operacje

• Plik jest zmieniany zarówno w lokalnym repozytorium, jak i wcześniej
  git pull:
  Git i tak zachowuje lokalne zmiany.
  W ten sposób nie stracisz przypadkowo żadnych danych oznaczonych dowolną z flag.
  • Plik z assume-unchangedflagą: Git nie nadpisuje lokalnego pliku. Zamiast tego generowałby konflikty i doradzał, jak je rozwiązać
  • Plik z skip-worktreeflagą: Git nie nadpisuje lokalnego pliku. Zamiast tego generowałby konflikty i doradzał, jak je rozwiązać

• Plik jest zmieniany zarówno w lokalnym repozytorium, jak i w górę, próbując i tak wyciągnąć. Wykorzystuje wyniki w dodatkowej pracy ręcznej, ale przynajmniej nie straciłbyś żadnych danych, gdybyś miał jakieś lokalne zmiany.
  git stash
git pull
skip-worktree
  • Plik z assume-unchangedflagą: odrzuca wszystkie lokalne zmiany bez możliwości ich przywrócenia. Efekt jest jak „ git reset --hard”. ' git pull' połączenie się powiedzie
  • Plik z skip-worktreeflagą: Skrytka nie działa na skip-worktreeplikach. „ git pull” zakończy się niepowodzeniem z takim samym błędem jak powyżej. Deweloper jest zmuszony ręcznie zresetować skip-worktreeflagę, aby móc ukryć i zakończyć awarię pull.

• Bez zmian lokalnych, zmieniono plik nadrzędny Obie flagi nie uniemożliwiłyby uzyskania zmian nadrzędnych. Git wykrywa, że ​​złamałeś obietnicę i postanawia odzwierciedlić rzeczywistość, resetując flagę.
  git pull
assume-unchanged
  • Plik z assume-unchangedflagą: treść jest aktualizowana, flaga została utracona.
    „ git ls-files -v” pokazuje, że flaga jest zmodyfikowana na H(z h).
  • Plik z skip-worktreeflagą: treść jest aktualizowana, flaga zostaje zachowana.
    „ git ls-files -v” Pokaże taką samą Sflagę jak przed pull.

• Po zmianie pliku lokalnego Git nie dotyka pliku i odzwierciedla rzeczywistość (plik, który obiecał pozostać niezmieniony, został zmieniony) dla pliku.
  git reset --hard
skip-worktreeassume-unchanged
  • Plik z assume-unchangedflagą: zawartość pliku jest cofana. Flaga jest resetowana do H(z h).
  • Plik z skip-worktreeflagą: zawartość pliku jest nienaruszona. Flaga pozostaje taka sama.

Dodaje następującą analizę:

• Wygląda na skip-worktreeto, że bardzo się starasz zachować swoje lokalne dane . Ale to nie zapobiega otrzymywaniu zmian, jeśli jest to bezpieczne. Plus git nie resetuje flagi pull.
  Ale zignorowanie polecenia „ reset --hard” może stać się przykrą niespodzianką dla programisty.

• Assume-unchangedFlaga może zostać utracona podczas pulloperacji, a lokalne zmiany w takich plikach nie wydają się być ważne dla git.

Widzieć:

• Komentarz Junio ​​(obecny opiekun git) dotyczący zamiaruassume-unchanged ,

  W szczególności, Junio zwraca uwagę, że zmiany w assume-unchangedplikach mógł zostać przypadkowo popełnione: „jeśli Git może określić ścieżkę, która jest oznaczona jako assume-unchangeduległ zmianie bez ponoszenia dodatkowych lstat (2) koszty, zastrzega sobie prawo do raportu, że tor został zmodyfikowany ( w rezultacie git commit -amoże zatwierdzić tę zmianę) ”.

• różnica między assume-unchangedi skip-worktreejak omówiono na liście mailowej git po dodaniu skip-worktreełatki .

Podsumowuje:

W rzeczywistości żadna z flag nie jest wystarczająco intuicyjna .

• assume-unchangedzakłada, że ​​programista nie powinien zmieniać pliku. Jeśli plik został zmieniony - zmiana ta nie jest ważna. Ta flaga służy do poprawy wydajności niezmienionych folderów, takich jak zestawy SDK.
  Ale jeśli obietnica zostanie złamana, a plik faktycznie zmieniony, git cofa flagę, aby odzwierciedlić rzeczywistość. Prawdopodobnie dobrze jest mieć niespójne flagi w folderach, których nie można zmienić.

• Z drugiej strony skip-worktreejest przydatny, gdy instruujesz git, aby nigdy nie dotykał określonego pliku. Jest to przydatne w przypadku już śledzonego pliku konfiguracyjnego.
  W głównym repozytorium nadrzędnym znajduje się konfiguracja gotowa do produkcji, ale chcesz zmienić niektóre ustawienia w konfiguracji, aby móc przeprowadzić lokalne testy. I nie chcesz przypadkowo sprawdzać zmian w takim pliku, aby wpłynąć na konfigurację produkcyjną. W takim przypadku skip-worktreetworzy idealną scenę.

W Git 2.25.1 (luty 2020 r.) Wspomniane powyżej „Właściwie żadna z flag nie jest wystarczająco intuicyjna” zostało wyjaśnione:

Zobacz zatwierdzenie 7a2dc95 , zatwierdzenie 1b13e90 (22 stycznia 2020 r.) Autor: brian m. carlson ( bk2204) .
^{(Scalony przez Junio ​​C Hamano - gitster- w commit 53a8329 , 30 stycznia 2020)}
( Git Mailing list )

doc: zniechęcaj użytkowników do ignorowania śledzonych plików

^{Podpisano: Jeff King
Podpisano: brian m. Carlson}

Użytkownicy często ignorują zmiany w pliku, który śledzi Git.

Typowymi scenariuszami w tym przypadku są ustawienia IDE i pliki konfiguracyjne, które zasadniczo nie powinny być śledzone i prawdopodobnie generowane z plików śledzonych przy użyciu mechanizmu szablonów.

Jednak użytkownicy dowiadują się o bitach „zakładaj niezmienione” i „pomiń”, i i tak próbuj ich użyć.

Jest to problematyczne, ponieważ po ustawieniu tych bitów wiele operacji zachowuje się zgodnie z oczekiwaniami użytkownika, ale zwykle nie pomaga, gdy git checkouttrzeba wymienić plik.

W tym przypadku nie ma rozsądnego zachowania, ponieważ czasami dane są cenne, takie jak niektóre pliki konfiguracyjne, a czasem nieistotne dane, które użytkownik chętnie odrzuci.

Ponieważ nie jest to obsługiwana konfiguracja, a użytkownicy są skłonni do niewłaściwego wykorzystywania istniejących funkcji do niezamierzonych celów, powodując ogólny smutek i zamieszanie , udokumentujmy istniejące zachowanie i pułapki w dokumentacji git update-index, aby użytkownicy wiedzieli, że powinni zbadać alternatywne rozwiązania.

Ponadto zapewnijmy zalecane rozwiązanie radzenia sobie ze zwykłym przypadkiem plików konfiguracyjnych, ponieważ istnieją dobrze znane podejścia stosowane z powodzeniem w wielu środowiskach.

git update-indexStrona podręcznika zawiera teraz:

Użytkownicy często próbują użyć bitów assume-unchangedi, skip-worktreeaby powiedzieć Gitowi, aby ignorował zmiany w śledzonych plikach. Nie działa to zgodnie z oczekiwaniami, ponieważ Git może nadal sprawdzać działające pliki drzewa pod kątem indeksu podczas wykonywania niektórych operacji. Ogólnie rzecz biorąc, Git nie umożliwia ignorowania zmian w śledzonych plikach, dlatego zalecane są alternatywne rozwiązania.

Na przykład, jeśli plik, który chcesz zmienić, jest jakimś plikiem konfiguracyjnym, repozytorium może zawierać przykładowy plik konfiguracyjny, który można następnie skopiować do zignorowanej nazwy i zmodyfikować. Repozytorium może nawet zawierać skrypt traktujący przykładowy plik jako szablon, automatycznie go modyfikując i kopiując.

Ta ostatnia część jest tym, co opisuję typowym sterownikiem filtru treści opartym na smudge / clean scripts .