Używanie Git do współpracy przy 4-osobowym projekcie

Question

W jednym z moich projektów uniwersyteckich jestem w grupie 4 programistów, których zadaniem jest opracowanie aplikacji internetowej od zera. Wszyscy mamy bardzo podstawową wiedzę na temat Gita i postanowiliśmy pójść z nim na współpracę w oparciu o kod, mamy repo ustawione i wszyscy są współpracownikami GitHub.

Przez ostatnie kilka miesięcy po prostu klonowaliśmy i wysyłaliśmy zamówienia do/z głównego oddziału, a to się udało. Ostatnio jednak zdarzały się sytuacje, w których dwie lub więcej osób pracowało nad bazą kodu naraz i często kończyło się to na tym, że niektórzy ludzie byli w tyle za zobowiązaniami i musieli sklonować repo przed wprowadzeniem, co czasami kończy się zmianą Stracony.

Dzisiaj jeden z członków grupy mówił o posiadaniu gałęzi "rozwojowej", którą wszyscy klonujemy i zobowiązujemy się do niej, a następnie połączyliśmy się z głównym oddziałem na końcu każdego sprintu. Próbowaliśmy tego, ale nie zauważyliśmy poprawy, ponieważ wciąż pracujemy z tej samej podstawy kodu, więc pojawia się ten sam problem, co poprzednio.

Ktoś inny wpadł na pomysł rozwidlenia (jest to dla mnie coś nowego) główne repozytorium, pracę nad nim, a następnie wysyłanie żądań ściągnięcia do głównego repozytorium, które można następnie połączyć. W praktyce brzmi to jak dobry plan, ponieważ zmiany mogą zostać sprawdzone i poprawione, jeśli złamie kod. I tak to rozumiem.

Ale jak już powiedziałem, wszyscy jesteśmy nowi dla Git i mamy bardzo podstawowe pojęcie o całej tej idei. Jaki jest standardowy sposób zorganizowania zespołu 4 programistów pracujących nad repozytorium Git? Przejrzałem dokumentację Git, ale jest to dość mylące dla kogoś, kto tylko wie, jak klonować i zatwierdzać do głównej gałęzi.

Dziękuję za pomoc!

Answer 1

Mówienie o rzeczach "standardowych" w metodologii rozwoju jest niebezpieczne, ponieważ prawie nie ma czegoś takiego. Grupy programistów zwykle organizują się w sposób, który działa na ich korzyść (lub sposób, w jaki kierownictwo każe im się organizować).

Wszystkie zidentyfikowane podejścia są prawidłowymi sposobami używania rozproszonych systemów kontroli wersji. Sugerowałbym, że nie widzisz ogromnych korzyści z alternatyw, ponieważ pracujesz nad projektem o zielonym polu uniwersyteckim z małym zespołem ludzi w tej samej lokalizacji geograficznej, mówiącym tym samym językiem, z podobnymi umiejętnościami iz podobnie jasne wyobrażenia o tym, jaki powinien być wynik. Git ma tendencję do błyszczeć, gdy takowe nie mają miejsca.

W przypadku projektów rozproszonych, w których naprawdę chce się, aby jedna osoba działała jako opiekun bramy w kanonicznej wersji projektu, żądania ściągania działają naprawdę ładnie. Gdy chcesz, aby wszyscy mieli faktycznie równy dostęp do commitowania, gałąź rozwojowa to dobre rozwiązanie. Ludzie mają tendencję do korzystania z gałęzi programistycznych, dzięki czemu mogą mieć zawsze działającą wersję, która będzie dostępna dla ludzi. Zakładam, że obecnie nie masz użytkowników, dlatego prawdopodobnie nie zauważysz dużej korzyści z takiego podejścia.

Zasadniczo kontynuowałbym tak, jak ty, chyba że ze sobą rozmawiasz i zdecydujesz, że coś nie działa dla ciebie jako zespołu, w takim przypadku możesz zdecydować, czy jeden z innych sposobów pracy będzie lepszy dla ty.

Answer 2

Musisz przejrzeć Git Workflow i/lub modele rozgałęzione. Istnieje wiele, a oto jeden zacząć:

A successful git branching model

Trzeba myśleć o pojęciu wersje, inscenizacji, produkcji i tak dalej, bo to może być łatwo reprezentowane. Chodzi w zasadzie o organizację.