Zarządzanie wieloma osobami pracującymi nad projektem za pomocą GIT

Jestem bardzo nowy w GIT / GitHub (nowy jak od wczoraj). Chciałbym wiedzieć, jaki jest najlepszy sposób zarządzania wieloma osobami pracującymi nad tym samym projektem z Github. Obecnie zarządzam jednym projektem z czterema programistami.

1. Jak przejść do przepływu pracy i upewnić się, że wszystko jest zsynchronizowane?

   (Uwaga: wszyscy programiści będą mieli jedno konto uniwersalne).

2. Czy każdy programista musi należeć do innego oddziału?

3. Czy będę w stanie obsłużyć 2 osoby pracujące nad tym samym plikiem?

Proszę zamieścić szczegółową odpowiedź, nie jestem nieśmiałym czytelnikiem. Muszę to dobrze zrozumieć.

Jeśli wszyscy programiści mają dostęp do repozytorium, nie trzeba robić nic specjalnego. Będą pobierać zmiany z repozytorium, wprowadzać własne zmiany, zatwierdzać lokalnie, a następnie wypychać z powrotem do repozytorium publicznego, gdy coś będzie działać.

Jeśli z drugiej strony masz jednego (lub kilku) programistów odpowiedzialnych za zatwierdzenie repozytorium, a inni dostarczają łatki do nich. Niech każdy z nich sklonuje repozytorium na swoich własnych kontach i niech wysyła żądania ściągania, gdy mają zmianę, którą chcą w głównej repozytorium.

Możliwe jest także tworzenie określonych klonów do pracy nad określonymi funkcjami, jeśli chcesz. Korzystanie z tego samego przepływu pracy z żądaniami ściągania w celu uzyskania zmian w głównym repozytorium po zakończeniu tej funkcji.

Jeśli przez „Wszyscy programiści będą mieli jedno konto uniwersalne” masz na myśli, że wszyscy programiści będą dzielić jedno konto GitHub i pojawiać się jako repozytorium w repozytorium, to zły pomysł. Utwórz osobne konta i skonfiguruj je jako współpracowników, jeśli chcesz, aby wszystkie miały dostęp do zatwierdzania.

Co do twoich konkretnych pytań:

2. Nie, używaj gałęzi dla funkcji, poprawek itp., Które zajmą więcej niż jedno zatwierdzenie. W tym samym oddziale może pracować więcej niż jeden programista.

3. Tak, git bardzo dobrze radzi sobie z konfliktami, więc nie ma problemów z tym, że ludzie pracują nad tym samym plikiem. Żadnych problemów, z wyjątkiem tego, że rozwiązywanie konfliktów nie zawsze może być trywialne, jeśli istnieją zasadnicze zmiany w pliku, który był edytowany przez więcej niż jednego członka. Nie jest to jednak nic, czego nie można pokonać rozmawiając ze sobą. Kontrola wersji nie zastępuje komunikacji.

Powodzenia!

Współpracujemy z 2 programistami i korzystamy z tego przepływu pracy:

• Na Github mamy gałąź master i gałąź dev
• Gałąź główna jest taka sama jak produkcja lub zawiera kod gotowy do wdrożenia
• Gałąź deweloperów wyprzedza master i zawiera cały nowy kod, nad którym obecnie pracujemy
• Lokalnie oboje pracujemy nad gałęzią deweloperów i pchamy do github, gdy coś jest gotowe
• Drugi deweloper pobiera wszelkie nowe zmiany z gałęzi deweloperów przed przekazaniem swojego nowego kodu
• Kiedy gałąź deweloperska jest dobra, łączymy się z gałęzią master
• Lokalnie mamy kilka oddziałów funkcji oddziałów wydawania itp.

Widzę tu tylko odpowiedzi tekstowe, więc pomyślałem, że na początek opublikuję zdjęcie fajnego gitflow. Zdjęcie opisuje ponad tysiąc słów:

• Ten przepływ działa również dobrze w przypadku ciągłego wdrażania.
• Gałąź główna zawiera kod, który jest obecnie uruchomiony na serwerze produkcyjnym.
• Twoja gałąź programistyczna zawiera kod, który jest obecnie uruchomiony na serwerze testowym / testowym.

Współpracuję z 3 innymi programistami i dość mocno się z tym zmagamy. Deweloperzy czasami wypychają zatwierdzenia do produkcji, które tak naprawdę nie są jeszcze gotowe na najwyższy czas, ponieważ wciągną inne zatwierdzenia do swoich zmian, a następnie wprowadzą do produkcji. Wydaje się, że gałęzie wersji działają dla nas dobrze. Jeśli więc wersja 1.0 jest bieżącą stabilną wersją, utworzymy gałąź dla rozwoju wersji 1.1. Programiści wprowadzą zmiany w tej branży. Nasz serwer testowy sprawdza tę gałąź i w razie potrzeby wprowadza zmiany. Kiedy wszystkie funkcje wersji 1.1 będą gotowe i testy zostaną zakończone, połączymy wersję 1.1 z funkcją master i push. W przypadku oddziałów zespół programistów A może pracować nad wersją 1.1, a zespół programistów B może pracować nad wersją 1.2. Oba zespoły mogą pracować bez wzajemnego oddziaływania. Jeśli zespół A opracuje coś, czego B może użyć,

Korzystamy również z gałęzi poprawek, która jest używana do natychmiastowych zmian.

Oto link do zdjęcia tego, jak to wygląda. http://nvie.com/img/git-model@2x.png