Wiele lat używałam Jedi vcs programując w Delphi.
Teraz używam gita, ma on zalety których tamten system nie posiada ale przydałoby się
Jeden plik na wiele repo - użyj submodułu. Jeśli chodzi o plik to robisz brancha, i tylko sobie nadajesz prawa do wypchana na niego zmian, po zakończeniu prac robisz merga do mastera a ludzie z pracą na innych branchach mogą zrobić rebase. Generalnie w git trzeba robić gałęzie i łączenie, dobieranie czy zmiana bazy to codzienny chleb w odróżnieniu od starych systemów jak CVS.
Ofc do mastera powinno być zablokowane mergowanie a tylko przez MR/PR to wtedy odrzucasz je z githuba/gitlaba i nikt nie zmieni ci pliku lub jej ważkiej części - bo rozumiem, że chodzi o ew. konflikty?
pragmaticdev napisał(a):
Ofc do mastera powinno być zablokowane mergowanie a tylko przez MR/PR to wtedy odrzucasz je z githuba/gitlaba i nikt nie zmieni ci pliku lub jej ważkiej części - bo rozumiem, że chodzi o ew. konflikty?
o konflikty też ale bardziej o info że ja coś w pliku poprawiam więc może reszta nie musi
No to taka modyfikacja powinna mieć taska na Jira i programiści tylko taki robią - wtedy nikt nie będzie robił podwójnie. Ofc w tych czasach Jira integruje się z Gitem, testami, CI/CD etc.
"z modułu korzystają dwa inne, błąd się objawia w obu inaczej ale to ten sam błąd w jednym module, wystrarczy go poprawić i wiele rzeczy z automatu zacznie działać ;)"
Ekstra świetnie, tylko ktoś i tak ktoś musi wykryć że "hej! Błąd w module A oraz błąd w module B to ten sam problem z modułu C!" - wtedy robisz taska / piszesz na slacku że: Panowie znalazłem! Jeśli nikt tego nie znalazł tzn nie wie że błąd z C wpływa na A oraz B to... żadna synchronizacja Ci nie pomoże. Jeśli masz predykat że C wpływa na A i już wtedy chcesz go blokować to możesz tak samo zrobić z taskiem + share info na grupie.
@lubie_programowac: ej ja nie pracuję w korpo, pracuję z ludźmi odpowiedzialnymi którzy błędy poprawiają jak znajdą a nie robią z nich nowe taski ;)
Nie myl korpokultury po prostu z porządkiem i organizacja pracy. Zrobienie taska to 30sekund a masz konkretne dane u historię co się działo z kodem. Znam takie odpowiedzialne zespoły co poprawiają jak widzą- zazwyczaj jest tam bałagan, brak wiedzy dlaczego cis jest tak a nie inaczej i dramat. Szczególnie jak ktoś odejdzie. Dlatego każdy redaktor powinien mieć taska i opis co i dlaczego. Głównie dla kolegów - obecnych i przyszłych.
Miang napisał(a):
pracuję z ludźmi odpowiedzialnymi którzy błędy poprawiają jak znajdą a nie robią z nich nowe taski
Pracuję nad pewnym projektem sam i dalej tworzę taski jak coś znajdę zepsutego lub mam pomysł na nową funkcjonalność. To po prostu ułatwia organizację i śledzenie różnych pomysłów i rozwiązań.
ej ja nie pracuję w korpo, pracuję z ludźmi odpowiedzialnymi
Ale nie umiecie się porozumieć? W normalnym świecie wystarczy napisać "poprawiam xyz" albo otworzyć merge request z work in progress żeby każdy wiedział że coś z tym robisz. Blokowanie pliku nic nie da, bo niby skąd ktoś ma wiedziec że poprawiasz akurat to co on chciał?
Git ma to do siebie, że:
Nic nie stoi na przeszkodzie, żeby zrobić zmiany w jednym pliku a potem wrzucić go do dwóch repozytoriów. Albo prościej: do jakichkolwiek zmian - choćby najmniejszych - zrobić oddzielną gałąź. Można nad czymś pracować, ale nie mergować. Koledzy, którzy chcą sprawdzić moje zmiany przed zmergowaniem, przełączają się na moją gałąź. Jak im się podoba, akceptują albo mogą zrobić cherry pick https://git-scm.com/docs/git-cherry-pick .
Tak że ten: gałęzie chyba są najprostszym rozwiązaniem. Git flow naszym przyjacielem.
Generalnie GIT to też inny styl pracy niż klasyczne systemy kontroli. Największe blokady są w głowie.
ej ja nie pracuję w korpo, pracuję z ludźmi odpowiedzialnymi którzy błędy poprawiają jak znajdą a nie robią z nich nowe taski ;)
komunikacja nie występuje tylko w korpo, a to wygląda jak problem z komunikacją :P
Miang napisał(a):
@lubie_programowac: ej ja nie pracuję w korpo, pracuję z ludźmi odpowiedzialnymi którzy błędy poprawiają jak znajdą a nie robią z nich nowe taski ;)
No to jak 5 osób poprawia to samo nie wiedząc o sobie nawzajem, to faktycznie odpowiedzialnie :)
Jira nie ma jeszcze takiego ficzuru, że jak stworzysz taska i go od razu weźmiesz i zaczniesz robić to przyzwie demony*. Jak widzisz buga to logujesz do Jiry, że jest taki i taki bug, jak znasz przyczynę to piszesz, że przez to i przez to. Jak ktoś (np Ty) weźmie tego buga z Jiry, to od razu wiadomo, że nie ma sensu, by pozostali też go niezależnie poprawiali.
* chyba że pracujesz w scrumie, to wtedy może przybiec scrum master
A co do ficzurów gita - branch chroniony (przed merge i push), opcjonalnie ustawiasz merge strategy na fast-forward only (unikniesz precli w historii commitów) i jak ktoś chce robić zmianę wychodzi z niego ze swoim branchem, robi co chce w izolacji i otwiera PR/MR.
pragmaticdev