Szukam lepszego gitignore

1

Uzależnij to od ustawienia środowiska, jak masz prod, to nie widzi tego kodu, a jak dev to widzi.

2

A od tego nie są poziomy logów?

To chyba powinno być w plikach konfiguracyjnych.

skoro te dodatkowe logi okazały się pomocne przy debugowaniu tego problemu to czy nie powinny zostać w projekcie?

I czemu nie warto tego testu i mocka wrzucić normalnie do repo skoro już istnieje?

Ogólnie prawie zawsze napisany kod powinien się znaleźć w repozytorium

Nie na wszystko zawsze ma się wpływ. Czasami panuje niedasizm i trzeba sobie radzić lokalnie.

Przykład: libka używana w projekcie, do której mam źródła ale do oficjalnego repo dostęp tylko read-only.
(akurat wtedy mogę mieć lokalnie branczę ze swoimi commitami, i robić rebase na master w razie potrzeby)

0
tsz napisał(a):

Da się to jakoś wyczarować?

Owszem, da. To bardzo proste rozwiązanie - nazywa się gałąź i jest podstawową funkcją gita. Gałąź trzymasz lokalnie, nigdy nikomu nie pokazujesz. Ja na wszelki wypadek wszystkie takie rozpoczynam prefiksem DONTPUSH. Sprawdza się doskonale od 10 lat.

Niezależnie oczywiście do tego, że lokalne poziomy logowania, urle i inne pierdoły powinny być skonfigurowane w lokalnym pliku konfiguracyjnym - ale to już od technologii, a nie gita zależy.

1
somekind napisał(a):
tsz napisał(a):

Da się to jakoś wyczarować?

Owszem, da. To bardzo proste rozwiązanie - nazywa się gałąź i jest podstawową funkcją gita.

ale co ma gałąź do tego? on chce pracować na konkretnej gałęzi którą wypchnie ale mieć lokalne zmiany w niektórych linijkach. Jak lokalna "gałąź" ma w tym pomóc? Czy masz na myśli zrobienie lokalnych zmian na gałęzi i jej mergowanie za każdym razem po checkoucie i revertowanie przed pushem?

W sumie chyba faktycznie gdyby to połączyć ze skryptami w triggerach które zrobią "niewidoczne commity" to chyba by się to dało tak zrobić. Ale łatwiej ze stashem.

Ja przyznam że w sumie mimo że tak prawię morały to mam podobny problem, bo często mam zmianę w jednej linijce żeby lokalnie udawać innego użytkownika w manualnych testach czego aplikacja normalnie nie wspiera bo ma integrację z domeną i używa automatycznie użytkownika domenowego bez możliwości zmiany. I to jest zmiana którą często mam, z tym że trzymam sobie ją normalnie w stashu i w miarę potrzeby robię apply i muszę potem pamiętać żeby jej przypadkiem nie dodać do indeksu ze wszystkim. Także całkowicie rozumiem autora wątku ale w moim przypadku nie robię tego tak często żeby było to uciążliwe. Chętnie się dowiem jak "gałąż" może mi pomóc

0
obscurity napisał(a):

ale co ma gałąź do tego? on chce pracować na konkretnej gałęzi którą wypchnie ale mieć lokalne zmiany w niektórych linijkach. Jak lokalna "gałąź" ma w tym pomóc?

Pozwala przechowywać zmiany.

Czy masz na myśli zrobienie lokalnych zmian na gałęzi i jej mergowanie za każdym razem po checkoucie i revertowanie przed pushem?

Bynajmniej. Po co mergować i revertować, skoro prościej po prostu nie commitować tych zmian?
Trzymasz swoje zmiany w gałęzi lokalnej, zaczynasz pracę na dowolnej innej gałęzi, jeśli potrzebujesz swoich lokalnych zmian, to robisz cherry picka tych zmian, korzystasz z nich, ale ich nie wrzucasz ich do gałęzi roboczej ani nie publikujesz w żaden sposób.

W sumie chyba faktycznie gdyby to połączyć ze skryptami w triggerach które zrobią "niewidoczne commity" to chyba by się to dało tak zrobić. Ale łatwiej ze stashem.

Ale na jakiej zasadzie stash jest łatwiejszy od gałęzi?
Jak dla mnie gałąź jest bardziej widoczna, a stash to w ogóle służy do tymczasowego przechowywania zmian. W tym przypadku zmiany chcemy przechowywać raczej długo.

1

Wygląda na problem X/Y.

Jeśli w jakiś sposób środowisko lokalne ma działać inaczej niż produkcyjne, to należałoby to jakoś uniezależnić, tak żebyś nie musiał pracować na dirty tree. Np property'sami, jak tu wielu próbowało.

2

przecież można w gicie zastage'ować pojedynczy hunk z pliku, ignorować też się powinno dać ale chyba na to nie wpadli

No nie, bo stage niejako "tworzy plik na nowo". Problemem tutaj byłyby operacje w postaci git status, które musiałby za każdym razem tworzyć diff by móc odfiltrować linie, które mają być zignorowane. To byłoby zdecydowanie za wolne, pomijając już fakt, że nie do końca pewne, bo zmiana ustawień w Gicie może spowodować zmianę diffa.

0

To jest problem XY, ale wg mnie to całkiem sensowny X do tego Y — tzn. jest to całkiem sensowne rozwiązanie problemu „chcę mieć coś innego lokalnie niż w głównym repo”. Konkurencyjne rozwiązania są, oczywiście, też sensowne, ale nie widzę oczywistej wyższości jednego nad drugim — „weź se tę wartość ze zmiennej środowiskowej” jest nieco uciążliwe w ustawianiu na produkcji czy czasem nawet przy testach i komplikuje nam infrastrukturę; „weź se tę wartość z pliku, którego nie commitujemy” ma podobny problem, jeśli się tego pliku nie wrzuca do repo, a jeśli jest wersja w repo, którą lokalnie nadpisujemy, to też nie jest najpiękniejsze, i wreszcie „weź se tę wartość taką, jaka jest, a niech system kontroli wersji tego nie wersjonuje” jest rozwiązaniem, rzekłbym, na poziomie tamtych dwóch — tyle że fundamentalnie sprzecznym z tym, jak działa git.

0

To nie bardzo jest problem X, jeśli rozwiązaniem X jest napisz od nowa w technologii, która wspiera różne bajery i w ogóle użyj rijakta i dokiera.

Przykład - praca nad API gatewayem, który korzysta z 40 wewnętrznych serwisów. Normalnie lokalnie mam ustawione na jakieś środowisko, ale wskakuje bug i trzeba zdebugować interakcję z 4 z tych serwisów. Stawiam je lokalnie, przekierowuję gateway na nie (reszta konfiguracji oczywiście zostaje bez zmian), mogę debugować. A ponieważ zdarza się to często, to mogę sobie tą zmienioną konfigurację wrzucić do gałęzi, i mieć lokalnie, następnym razem zrobię tylko cherry picka i będę miał środowisko gotowe do debugowania.

0

Polecam .dockerignore

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