Przepływ pracy zespołu github - rozwidlić czy nie?

Jesteśmy niewielkim zespołem programistów internetowych, którzy obecnie używają subversion, ale wkrótce przechodzimy na github.

Patrzę na różne rodzaje przepływów pracy github i nie jesteśmy pewni, czy cała koncepcja rozwidlania w github dla każdego programisty jest dla nas tak dobrym pomysłem.

Jeśli korzystamy z widelców, rozumiem, że każdy programista będzie miał swoje prywatne zdalne i lokalne repozytoria. Martwię się, że spowoduje to, że pchanie zestawów zmian będzie trudne i zbyt złożone. Moim największym zmartwieniem jest to, że zmusi każdego programistę do posiadania 2 pilotów: origin (który jest zdalnym rozwidleniem) i upstream (który służy do „synchronizacji” zmian z głównego repozytorium). Nie jestem pewien, czy to taki łatwy sposób na robienie rzeczy.

Jest to podobne do przepływu pracy opisanego tutaj: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

Jeśli nie użyjemy widelców, prawdopodobnie uda nam się to osiągnąć, używając centralnego repozytorium, tworząc gałąź dla każdego zadania, nad którym pracujemy, i scalimy je z gałęzią programistyczną w tym samym repozytorium. Oznacza to, że nie będziemy w stanie ograniczyć łączenia gałęzi i może być trochę bałagan, gdy wiele oddziałów znajduje się w centralnym repozytorium.

Jakieś sugestie zespołów, które wypróbowały oba procesy?

Myślę, że twój strach przed rozwidleniem wynika z mniej niż gwiazdowego łączenia SVN - ponieważ to nie rozwidlenie powoduje problemy - to połączenie.

Zanurz się - przekonasz się, że to naprawdę świetne! Nie trzeba rozwidlać (nie rozwidlać dla każdej zmiany w każdym pliku), ale można rozwidlać funkcje i scalać się z powrotem.

Pomyśl o GitHub jako o kilku wersjach wartych ulepszenia w wielu podstawowych koncepcjach kontroli źródła.

Koncepcja „stabilnej” gałęzi i widelca „aktywnego rozwoju” obejmuje również wiele z tych zagadnień, jeśli nie masz ochoty rozwodzić się. : P

Wypróbowaliśmy oba, z programistami, którzy są bardzo u siebie w svn. A jeśli jesteś grupą programistów, którzy już pracują razem i ufają sobie nawzajem z uprawnieniami do zatwierdzania, prawdopodobnie łatwiej będzie ci zachować jedno, centralne repo w git i dodać was wszystkich jako współpracowników, którzy to repozytorium.

Nadal czasami robimy prywatne widelce, ale zwykle dotyczy to egzotycznych zmian lub jednoosobowych testów, których reszta zazwyczaj nie jest zainteresowana, ale i tak chcemy przechowywać zdalnie.

Zaczynam od jednego, centralnego repozytorium i po prostu pracuję z git przez chwilę. Może rozwinie się na ciebie prywatny widelec, a może nie. Albo jedno jest w porządku.

W git, widelec to tak naprawdę kolejna gałąź. Dzięki obiegowi pracy dla każdego programisty efektywnie nakazujesz, aby każdy programista miał publiczny (zdalny) oddział do śledzenia zmian w programowaniu. Jest to pomocne, ponieważ umożliwia bezpośrednią współpracę między programistami (peer-to-peer). W każdym razie będziesz musiał scalić zmiany każdego dewelopera z centralnym repozytorium, więc nie sądzę, aby było to związane z dużym nakładem pracy.

W przypadku niewielkiego zespołu złożonego z 2-3 programistów można używać rozgałęzień w repozytorium do zarządzania poprawkami i funkcjami. Problem polega na tym, że masz więcej programistów i więcej opracowywanych funkcji i poprawek.

W takim przypadku twoje główne repozytorium w Github będzie miało setki oddziałów; niektórzy będą starzy, zapomniani i rozproszeni.

Będziesz także mieć problemy ze współpracą, gdy ktoś będzie forsował wspólną gałąź, która jest na repozytorium. Oznacza to, że nikt nie może właściwie współpracować w tej gałęzi, ponieważ wymuszenie jest przepisaniem historii.

Rozwidlenie repozytorium ułatwia śledzenie, które gałęzie są w trakcie realizacji, a które są dobre. Utrzymuje czystość głównego repozytorium.

Jednak twoja infrastruktura testowa może polegać na użyciu głównego repozytorium, więc może być trudniej przetestować zmiany w rozwidlonym repo, chyba że zepchnąłeś gałąź do góry. Ustalenie, kiedy rozgałęzienia i rozwidlenia są najlepsze, może być trudne, ale ogólnie, gdy zespół ma więcej niż 4 osoby i jest wiele poprawek i funkcji, rozwidlenie jest najlepszą opcją.