Git: Jak zapobiegać zatwierdzaniu plików, które zostały zmodyfikowane tylko w celu debugowania?

Question

Wiele razy lubię modyfikować niektóre linie kodu, aby ułatwić sobie debugowanie, ale tak naprawdę nie chcę ich zatwierdzać. Na przykład wyłączę niektóre irytujące funkcje (takie jak reklamy), komentując niektóre wiersze kodu, lub ustawię poziomy dzienników i filtry tylko dla tych, na których mi zależy, lub wymuszę spełnienie warunku, aby było prawdziwe tak więc blok kodu, który chcę uruchomić, działa cały czas.

W Perforce utworzyłbym "listę zmian" dla tych plików i oznaczono ją jako "NIE ZATWIERDZ!". Jaki byłby odpowiednik tego w Git? Oddział nie działa, ponieważ te modyfikacje związane tylko z debugowaniem muszą istnieć wraz z innymi zmianami, które obecnie wprowadzam.

Answer 1

Dziękuję wszystkim za odpowiedzi. To, co w końcu robiłem, to pisanie wstępnego zatwierdzenia w git, które sprawdza ciąg "dont commit" (i inne odmiany) w każdym z plików. Jeśli tak, to zatwierdzenie nie powiedzie się i będę musiał edytować te linie przed zatwierdzeniem. Dzieje się tak dlatego, że kod debugowania powinien być traktowany osobno, a nie osobno, ponieważ niektóre pliki zawierają zarówno zmiany debugowania, jak i prawdziwe zmiany, które mają zostać zatwierdzone. (moje stare rozwiązanie z perforce nie rozwiązało tego problemu).

Answer 2

Wyszukiwanie opcji --assume-unchanged. Istnieje artykuł na blogu about this, który całkiem dobrze wyjaśnia rzeczy. A także this one, który wspomina o późniejszym wyszukiwaniu takich ignorowanych plików.

Answer 3

Zazwyczaj po prostu umieszczam kod debugowania w jego własnym zatwierdzeniu i cofam to zatwierdzenie później. Bardziej zaangażowanym rozwiązaniem jest utworzenie oddziału pośredniego z master, nazwijmy go debug. Wprowadź wszystkie zmiany debugowania w gałęzi debug, a następnie wyłącz gałąź funkcji z debug. Kiedy będziesz gotowy, aby usunąć zmiany debugowania, po prostu zmień gałąź swojej funkcji na master.

Answer 4

W rzeczywistości nie chcesz ignorować tych plików, ale zignoruj ​​te zmiany.

Widzę dwa rozwiązania tutaj:

1. Restore HEAD

Polecenie używam dla takiej sytuacji jest:

git checkout -- file ... 

Z wszystkich plików zmodyfikowanych do debugowania cel, powód.

Spowoduje to przywrócenie pliku z dnia HEAD. Następnie możesz bezpiecznie wykonać swoją git commit -a lub cokolwiek innego.

2. powiedzieć git zapytać, co zmienia popełnić (w jednym pliku)

   git add -p.

Zobacz #1085162.

Ale nadal musisz usunąć kod debugowania.

Answer 5

Jednym z rozwiązań, który nie jest uniwersalny, ale może pasować do niektórych scenariuszy przepływu pracy, jest zastosowanie filtrów pre-commit Gita (manual, manual + samples).W skrócie, jest to tylko narzędzie do przetwarzania wstępnego, które będzie wywoływane przez wszystkie zatwierdzone pliki przed faktycznym zatwierdzeniem. Możesz mieć ten mechanizm do usuwania pewnych wzorców, takich jak //<NOCOMMIT ... //NOCOMMIT> lub cokolwiek chcesz. Wadą jest to, że te linie debugowania mogą zniknąć po zresetowaniu do zatwierdzenia lub nawet pociągnięciu/scaleniu (tego nie sprawdziłem).