Szukam lepszego gitignore

1

Potrzebowałbym tak ustawić gita, żeby zupełnie ignorował pewne zmiany. Znaczy mam zrobione trochę swoich zmian lokalnych, ale nie chcę ich nigdy commitować i wolałbym, żeby git je całkowicie ignorował. Zdaje się, że można zrobić sobie lokalnego gitignore, ale to nie rozwiązuje wszystkich problemów, bo żeby to były pojedyńcze zmiany, a nie całe pliki. To jest mam na przykład w jednym pliku zmienione coś w linii 2, ale w pewnym momencie dopisuje coś w linii 4 i chciałbym, żeby chamskie git add bez -p wzięło pod uwagę tylko te zmiany w linijce numer 4.

Da się to jakoś wyczarować?

0

git stash powinno Ci pomóc.

1

Nie, bo Git operuje na plikach, nie na pojedynczych zmianach. To by wymagało patch-based VCS jak Darcs lub Pijul.

1

Problem brzmi jakby w projekcie brakowało plików .env, tj. dev.env (ew. local.env), prod.env itp. - macie takie pliki albo coś podobnego?

0
Markuz napisał(a):

Problem brzmi jakby w projekcie brakowało plików .env, tj. dev.env (ew. local.env), prod.env itp. - macie takie pliki albo coś podobnego?

Mamy. Wszystko jest w ignorach. Chodzi o pliki, które nie zostały stworzone z myślą o lokalnej konfiguracji. Jak na przykład bajerek do analizy przy testach. W większości przypadków tylko wydłuża startup, odkomentowuję go tylko, gdy task jest już zrobiony, żeby zobaczyć czy coś się nie rypło.

2

A mnie zastanawia po co? To oznacza, że twoja wersja ma działać inaczej jak wszystkie inne. Jak w takim wypadku coś debugować ?

3

Wydaje mi się, że środowiska IntelliJ ogarniają takie zmiany w ramach changelist - tj. jeśli dorzucisz jakieś zmiany do osobnej changelisty, nie będą one Ci się pokazywały w trakcie commitowania.

2
UglyMan napisał(a):

A mnie zastanawia po co? To oznacza, że twoja wersja ma działać inaczej jak wszystkie inne. Jak w takim wypadku coś debugować ?

Choćby dlatego że chcemy by nasza wersja miała dodatkowe printy w logach.
Albo mniej śmieciowych printów w logach.
Albo zamockowane coś właśnie po to by się dało debugować czy testować.
Albo inny adres serwera (np. localhost).

Jest wiele takich sytuacji, kiedy chcemy mieć lokalnie jakieś zmiany na stałe lub na półstałe a jednocześnie nie wypychać ich do repo.

2
Azarien napisał(a):
UglyMan napisał(a):

A mnie zastanawia po co? To oznacza, że twoja wersja ma działać inaczej jak wszystkie inne. Jak w takim wypadku coś debugować ?

Choćby dlatego że chcemy by nasza wersja miała dodatkowe printy w logach.
Albo mniej śmieciowych printów w logach.

A od tego nie są poziomy logów?

Albo zamockowane coś właśnie po to by się dało debugować czy testować.

No to chyba na developerce wszyscy maja zamockowane

Albo inny adres serwera (np. localhost).

To chyba powinno być w plikach konfiguracyjnych.

3
hauleth napisał(a):

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.

Azarien napisał(a):

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0