Szukam lepszego gitignore

2
TomRiddle napisał(a):

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.

Ale - jak już wyżej napisałem - to nie jest zawsze możliwe. Powiedzmy że te nasze lokalne zmiany są tyle genialne co kontrowersyjne i dziwaczne i nie spotkały się z aprobatą reszty zespołu.

0
Azarien napisał(a):
TomRiddle napisał(a):

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.

Ale - jak już wyżej napisałem - to nie jest zawsze możliwe. Powiedzmy że te nasze lokalne zmiany są tyle genialne co kontrowersyjne i dziwaczne i nie spotkały się z aprobatą reszty zespołu.

Sposób ich wykonania ("nasz sposób") możliwe że jest kontrowersyjny i dziwaczny, ale jego zasadność prawdopodobnie nie. I być może zespół znajdzie lepsze rozwiązanie. Jak np podmiana hosta w kodzie źródłowym jest dziwacznym rozwiązaniem, ale uniezależnienie się od jednej domeny jest zasadne, i team mógłbym znaleźć alternatywę.

Jeśli natomiast cały pomysł zostanie uznany za niezasadny przez zespół, to czemu taki osobnik ciągle chciałby kontynuować taką praktykę?

Co ma na tyle sensu żeby ryzykować pracę na dirty tree, ale tak mało żeby czyjś zespół nie chciał dać takiej możliwości każdemu?

1
somekind napisał(a):

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.

Podałem wyżej przykład, gdzie takie coś jest potrzebne jednej konkretnej osobie, ale nie całemu zespołowi. - somekind 11 minut temu

Tylko ten przykład brzmi jak coś jednokrotnego. Jakby, ile razy można naprawiać tego samego buga? Najpewniej go fixniesz raz, potem popraiwsz jak coś dalej nie będzie działać i tyle. Po fixie, pewnie nie wrócisz do tych lokalnych zmian które miałeś.

Autor wątku sugeruje takie dirty local tree, które jest utrzymywane cały czas, niezależnie od tego nad jakim feature'em pracuje.

0
TomRiddle napisał(a):

Tylko ten przykład brzmi jak coś jednokrotnego. Jakby, ile razy można naprawiać tego samego buga? Najpewniej go fixniesz raz, potem popraiwsz jak coś dalej nie będzie działać i tyle. Po fixie, pewnie nie wrócisz do tych lokalnych zmian które miałeś.

Jednego buga jeden raz, ale zawsze mogą pojawić się nowe bugi na styku tych samych serwisów, więc trzeba te zmiany mieć ciągle dostępne.

2

Podam przykład z życia jak rozwiązano problem z hardkodowanym adresem serwera.

Początkowo serwer był stringiem zdefiniowanym w (dużym) pliku źródłowym. To powodowało niekomfortową sytuację że często pracowało się przy „brudnym” tym akurat (dużym) pliku.
W końcu ktoś wpadł na pomysł żeby adres serwera wyciągnąć do osobnego, małego pliku, w którym będzie zdefiniowany praktycznie tylko ten adres.
To już lepiej, bo możemy się przyzwyczaić do ignorowania zmian w tym pliku, ale nadal to jest praca na “dirty tree”.
Plik więc zamiast normalnie być w repo jest teraz generowany jako jeden z pierwszych etapów budowania projektu (robienie builda ma kilka faz, to nie jest jedno make). Po tym pierwszym etapie możemy wyedytować plik z adresem i odpalić właściwą kompilację.
Nic nam nie brudzi bo generowany plik jest w gitignore.

Wadą rozwiązania jest że możemy (w zależności od tego jak odpalimy make'a) niechcący nadpisać plik przywracając adres domyślny.

0

Teoretyczna obsługa takiego ficzera przez hipotetyczny neo-git miałaby też tę zaletę, że umiarkowanie łatwo byłoby się edytorom/IDE podpiąć pod nią i być w stanie wyświetlać od razu/na żądanie obu wersji — moglibyśmy widzieć od razu, że u nas jest taka, a na produkcji taka. Coś, co jest drastycznie trudniejsze do osiągnięcia w jakikolwiek „normalny” sposób.

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