Czy dobrą praktyką jest posiadanie zdalnego oddziału dla każdego programisty?

Czy dobrą praktyką jest posiadanie zdalnego oddziału dla każdego dewelopera w projekcie?

Używamy Git z następującymi gałęziami:

• mistrz
• wydanie
• rozwijać

Gdyby każdy programista miał swoją gałąź, mogliby wepchnąć kod do swoich gałęzi, a inni mogliby scalić te zmiany we własnych gałęziach.

Nie! Dobrą praktyką jest posiadanie zdalnej przestrzeni nazw gałęzi dla każdego programisty.

Pojedyncza gałąź często nie wystarcza, więc programista albo często ją przewija, albo nie byłby zbyt pomocny. Raczej chcesz powiedzieć, że programista może pchać co tylko zechce pod swoją nazwą/ . Mogą go używać do publikowania wersji zapoznawczych dla innych, dając wersję do przetestowania przez kogoś innego, a nawet do zintegrowania.

Możesz użyć tego również do nadania gałęzi integratorowi lub możesz użyć nazw opartych na zadaniach. Nazwy zadaniowe są zazwyczaj łatwiejsze do śledzenia dla integratora, ale zmuszają programistów do myślenia o nazewnictwie, a ludzie nie lubią myśleć. Nie wiem, które będą działać lepiej w praktyce; może nawet zależeć od konkretnego zespołu.

Prawdopodobnie nie dałbym każdemu deweloperowi gałęzi na centralnym serwerze, chyba że masz jakąś infrastrukturę w stylu github, która pozwala im tworzyć i niszczyć gałęzie i jasno dokumentować, po co są. Niektórzy programiści będą potrzebować więcej niż jednej gałęzi, a niektórzy wcale nie będą potrzebować żadnej, ale tworzysz bałagan dla wszystkich do posortowania i administracyjne obciążenie dla siebie.

W zamian zachęciłbym do tego rodzaju organicznego dzielenia się gitem. Utworzenie klonu na własnym komputerze jest bardzo łatwe i uczynienie z tego folderu udostępniania SMB tylko do odczytu dla innych. W rzeczywistości bardzo by mnie zaskoczyło, gdyby kilku twoich programistów jeszcze tego nie robiło.

To zależy od tego, jak zorganizowany jest zespół programistów i zadania. Moim zdaniem model, który określiłeś, działałby najlepiej, gdyby:

1. Każdy programista samodzielnie wykonuje niezależne zadania.
2. Wszyscy programiści przyczyniają się do tego samego zadania.

To może nie działać dobrze, jeśli masz równoległe projekty funkcji w fazie rozwoju i każdy z nich ma wielu programistów pracujących nad nimi.

Przydzielenie każdemu deweloperowi własnego oddziału może być pomocne, jeśli wszyscy pracują nad różnymi rzeczami, które mogą dotykać tych samych plików. Może to pomóc w uniknięciu nadepnięcia na siebie, ale będzie wymagało częstego łączenia się i odpowiedzialności za zarządzanie konfliktami. Tak właśnie dzieje się w moim biurze i działa całkiem dobrze, z wyjątkiem rzadkiego dnia, w którym musisz ręcznie scalić połowę edytowanych plików.

Jeśli masz wielu programistów pracujących nad tą samą funkcją, prawdopodobnie lepiej jest tworzyć gałęzie na podstawie funkcji w fazie rozwoju niż programisty.

Jeśli pracujesz z Git, powinieneś wypróbować Pull Requests.

Podsumowując, najpierw łączysz gałąź główną z bieżącą gałęzią roboczą. Wszelkie konflikty scalania będą miały miejsce w lokalnym oddziale. Jest to miłe, ponieważ twoja główna gałąź nigdy nie jest zepsuta. Jeśli naprawdę spieprzysz, masz lokalne zatwierdzenie, do którego możesz wrócić.

Po zakończeniu scalania poprosisz kogoś innego z zespołu o przejrzenie i połączenie twojego oddziału w główny oddział. Nigdy nie łącz własnych! Tak długo, jak nikt się nie wkradnie i nie wykona kolejnej prośby Pull, masz gwarancję, że połączenie zostanie pomyślnie zakończone. Ponieważ wszyscy są świadomi żądania ściągnięcia, nie powinno być tak, że wiele osób łączy się jednocześnie w master.

Kiedy już przyzwyczaisz się do tego procesu, powinieneś próbować łączyć się tak często, jak to możliwe - coś w rodzaju ciągłej integracji biedaka. Im mniej czasu między konfliktami, tym lepiej. Zidentyfikujesz, kiedy dwoje ludzi powiela wysiłek i mogą połączyć siły. Niektóre miejsca będą się łączyć za każdym razem, gdy spełnią wymagania, co może trwać kilka godzin. Zalecam łączenie przynajmniej raz w tygodniu; w przeciwnym razie musisz lepiej rozdzielić swoje zadania.

Zwykle tworzę jedną gałąź dla każdego zadania. Git jest fajny, ponieważ rozróżnia lokalne zatwierdzenia i wypychania. Zapewnia to pewne korzyści każdej osobie, która ma swój oddział bez całej złożoności.