Nie, bo Git operuje na plikach, nie na pojedynczych zmianach. To by wymagało patch-based VCS jak Darcs lub Pijul.
przecież można w gicie zastage'ować pojedynczy hunk z pliku, ignorować też się powinno dać ale chyba na to nie wpadli
Lepiej wydzielić zmienne które mają się różnić do osobnego configa, wtedy można mieć lokalną wersję która będzie zignorowana. W kodzie może być warunek typu "jeśli plik .config.local istnieje to go użyj, jak nie to zwykły", albo wybierać config na podstawie środowiska.
Choćby dlatego że chcemy by nasza wersja miała dodatkowe printy w logach.
Mieliśmy kiedyś w projekcie podobną rozkminę i ktoś rzucił moim zdaniem słusznie - skoro te dodatkowe logi okazały się pomocne przy debugowaniu tego problemu to czy nie powinny zostać w projekcie? Więc tylko zmieniliśmy poziom logowania na trace i normalnie wrzuciliśmy to do kodu.
Albo zamockowane coś właśnie po to by się dało debugować czy testować.
I czemu nie warto tego testu i mocka wrzucić normalnie do repo skoro już istnieje?
Albo inny adres serwera (np. localhost).
to już napisałem wyżej.
Ogólnie prawie zawsze napisany kod powinien się znaleźć w repozytorium. Lokalne configi np z IDE mają zazwyczaj konkretne nazwy albo są ukryte w podfolderach więc łatwo je zignorować.
Ale jeśli nadal Ci na tym zależy to mogę zaproponować obejście wykorzystujące symlinki (ln
na linuksie, mklink
na windowsie). Wystarczy że obok klona repo stworzysz sobie folder ze swoimi zmianami i stworzysz dowiązania do reszty plików i folderów (najłatwiej w ten sposób podmienić cały folder). Potem lokalnie korzystasz z tego nowego folderu a ten pierwszy, z working copy używasz tylko do commitowania i pushowania zmian.
To nie rozwiązuje problemu zmian w pojedynczych liniach, ale umożliwia trzymanie zmian bez ich ręcznego ignorowania za każdym razem i bez wrzucania pliku do .gitignore.
Możesz lokalnie postawić skrypt który będzie mergował zmiany z głównego folderu do dodatkowego. Możesz utworzyć z tego drugiego folderu lokalne repozytorium i użyć gita do mergowania, podpiąć się pod trigger post-update
tego pierwszego i to wszystko zautomatyzować.
Minus takiego rozwiązania to że być może będziesz musiał ręcznie tworzyć nowe dowiązania i usuwać stare jeśli struktura plików się zmieni.