Mam taki problem mam np. 2 gałęzie np. develop i release. Co jakiś czas developerzy merge'ują develop do release ale niestety nadpisują mi kilka plików które nie powinny się zmieniać. Chciałbym wyłączyć merge dla tych kilku plków. Próbowałem za pomocą "lock" ale wtedy gitlab nie pozwala na zrealizowanie merge request do końca informując iż zablokowałem kilka plików. Czy da się zrealizować takiego merge pomijając niejako zalockowane pliki? Czy może powinienem to zrealizować inaczej?
Giitignore też mi tutaj nie zdaje egzaminu czy ktoś podpowie jak się zabezpieczyć aby pomimo akceptacji w merge req. pliki były chronione i nie dało się ich nadpisywać?
- Rejestracja:prawie 7 lat
- Ostatnio:11 miesięcy
- Postów:88
0
- Rejestracja:ponad 12 lat
- Ostatnio:około 3 godziny
- Postów:1435
- Rejestracja:około 5 lat
- Ostatnio:5 miesięcy
- Postów:2420
1
Możesz też zmienić model, czyli mieć jeden develop i od niego "odrywać" releasy. Działa znacznie lepiej IMHO.
Jeżeli korzystasz z dobrego narzędzia do code review + każdy merge też idzie przez ten tool to możesz sobie ustawić tzw. CODEOWNER czyli zmiana zbioru plików skutkuje tym że automatycznie zostaniesz dodany do review.
Generalnie nie wiem co to za pliki, ale coś tutaj śmierdzi. Te pliki generują się automatycznie czy to jakieś wersję itp.?
- Rejestracja:prawie 7 lat
- Ostatnio:11 miesięcy
- Postów:88
0
@0xmarcin: to pliki konfiguracyjne, każda gałąź ma je inne ale dev'sy czasami sobie przypominają o merge i bez namysłu merge'ują zmiany z develop to release a potem na szybko z release do release2 i nie patrzą że merge nadpisuje nie tylko "ich" pliki ale także konfiguracyjne
- Rejestracja:ponad 13 lat
- Ostatnio:około 12 godzin
- Postów:1068
0
Czemu każda gałąź ma indywidualne pliki konfiguracyjne o.0 ? Rozumiem, że to jakieś pliki do konfiguracji env na danym stagu ?
tak, każda gałąź posiada konfigurację dla innego środowiska
IMO to trochę dziwne i nie dziwię, że się ludzie jebią sam bym pewnie przynajmniej raz w tygodniu się mylił. Ale pewnie macie case zeby tam to trzymać jednak jeśli nie to warto by sie zastanowić czy to dobre miejsce jest. Ew pytanie czy nie lepiej trzymać wszystkie konfiguracje w jednym miejscu i tylko na etapie CI/CD wybierać które to środowisku i z którego configu czytać.
problem w tym że jedna gałąź jest 1:1 przepychana do klienta więc lepiej żeby była wypychana tam tylko jedna (jego) konfiguracja
czy ten kod to jest do IaS czy konfiguracja statycznego srodowiska? W każdym razie trzymanie rzeczy który nigdy nie będą mergowane na róznych gałęziach to gwałcenie gita i kontroli wersji. Bo ty nie kontrolujesz wersji tego pliku tylko masz logicznie wiele plików o tej samej nazwie.
Jeśli jest to statyczny szajs to powinno być po prostu na danym env i tyle. A różnice powinny być w dokumentacji :).
- Rejestracja:około 17 lat
- Ostatnio:około 15 godzin
- Lokalizacja:Wrocław
4
Jeśli konfiguracja jest zmienna per środowisko, to powinna się znajdować w zmiennych środowiskowych (nazwa pewnie dla zmyłki, żeby nikt nie wpadł, do czego służą ;]). A w kodzie nie trzyma się wartości tylko nazwy tychże zmiennych. I problemu nie ma.
A poza tym Git flow to syf i powinien zostać zniszczony.
edytowany 1x, ostatnio: somekind
- Rejestracja:ponad 7 lat
- Ostatnio:8 dni
- Postów:3277
1
Przenieść z repozytorium do konfiguracji (w innym repozytorium?) i nadpisywać podczas builda.
Wyciągnąć konfigurację do zmiennych środowiskowych, pliku poza artefaktem, robić z automatu osobne buildy z osobnymi wartościami.
Doraźnie:
Systematycznie op..... tego kto zatwierdził PR
Osobny branch dla każdego środowiska/klienta itd. brzmi jak ostra patologia.
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.
99xmarcin