Kontrola źródła oparta na Git w przedsiębiorstwie: sugerowane narzędzia i praktyki?

Używam gita do osobistych projektów i uważam, że jest świetny. Jest szybki, elastyczny, wydajny i świetnie sprawdza się w przypadku programowania zdalnego.

Ale teraz jest to obowiązkowe w pracy i, szczerze mówiąc, mamy problemy.

Po wyjęciu z pudełka, git wydaje się nie działać dobrze w scentralizowanym rozwoju w dużej organizacji (ponad 20 programistów) z programistami o różnych umiejętnościach i poziomach zaawansowania git - szczególnie w porównaniu z innymi systemami kontroli źródła, takimi jak Perforce lub Subversion, które są skierowane do tego rodzaju środowiska. (Tak, wiem, Linus nigdy tego nie zamierzał.)

Ale - z powodów politycznych - utknęliśmy w dupie, nawet jeśli to jest do bani z powodu tego, co próbujemy z nim zrobić.

Oto kilka rzeczy, które widzimy:

• Narzędzia GUI nie są dojrzałe
• Korzystając z narzędzi wiersza poleceń, bardzo łatwo jest zepsuć scalanie i zatrzeć czyjeś zmiany
• Nie oferuje uprawnień repozytorium dla każdego użytkownika poza globalnymi uprawnieniami tylko do odczytu lub odczytu i zapisu
• Jeśli masz pozwolenie na DOWOLNĄ część repozytorium, możesz zrobić to samo z KAŻDĄ częścią repozytorium, więc nie możesz zrobić czegoś takiego, jak utworzenie gałęzi śledzenia małej grupy na serwerze centralnym, czego inni ludzie nie mogą zadzierać z.
• Przepływy pracy inne niż „wszystko idzie” lub „życzliwy dyktator” są trudne do zachęcania, nie mówiąc już o egzekwowaniu
• Nie jest jasne, czy lepiej jest używać jednego dużego repozytorium (które pozwala wszystkim majstrować we wszystkim), czy wielu repozytoriów dla poszczególnych komponentów (co powoduje ból głowy przy próbie synchronizacji wersji).
• W przypadku wielu repozytoriów nie jest również jasne, jak replikować wszystkie źródła, które ktoś inny ma, wyciągając z centralnego repozytorium lub zrobić coś takiego, jak uzyskać wszystko od wczoraj o 4:30 po południu.

Słyszałem jednak, że ludzie z powodzeniem używają git w dużych organizacjach programistycznych.

Jeśli jesteś w takiej sytuacji - lub jeśli ogólnie masz narzędzia, porady i wskazówki, które ułatwiają i zwiększają produktywność korzystania z git w dużej organizacji, w której niektórzy ludzie nie są fanami wiersza poleceń - chciałbym usłyszeć, co masz sugerować.

Swoją drogą, zadałem już wersję tego pytania na LinkedIn i nie otrzymałem żadnych prawdziwych odpowiedzi, ale dużo „rany, też chciałbym to wiedzieć!”

AKTUALIZACJA: Pozwól mi wyjaśnić ...

Tam, gdzie pracuję, nie możemy używać niczego innego niż git . To nie jest opcja. Utknęliśmy z tym. Nie możemy używać Mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, ani nawet starego dobrego projektora Apple, którego używałem w 1987 roku. Więc chociaż możesz omówić inne opcje, nie dostaniesz nagrody, jeśli nie porozmawiasz o git.

Szukam również praktycznych wskazówek, jak używać git w przedsiębiorstwie . Na początku tego pytania umieściłem całą listę problemów związanych z praniem. Ponownie, zapraszam ludzi do dyskusji na temat teorii, ale jeśli chcesz zasłużyć na nagrodę, daj mi rozwiązania.

Wbrew powszechnej opinii uważam, że korzystanie z DVCS jest idealnym wyborem w środowisku korporacyjnym, ponieważ umożliwia bardzo elastyczne przepływy pracy. Opowiem najpierw o używaniu DVCS vs. CVCS, najlepszych praktykach, a następnie w szczególności o git.

DVCS a CVCS w kontekście przedsiębiorstwa:

Nie będę tutaj mówić o ogólnych zaletach / wadach, ale skupię się na twoim kontekście. Powszechnie uważa się, że korzystanie z DVCS wymaga bardziej zdyscyplinowanego zespołu niż korzystanie z systemu scentralizowanego. Dzieje się tak, ponieważ scentralizowany system zapewnia łatwy sposób egzekwowania przepływu pracy przy użyciu zdecentralizowanego systemu większej komunikacji i dyscypliny, aby trzymać się ustalonych konwencji. Chociaż może się to wydawać, że powoduje to obciążenie, widzę korzyści w zwiększonej komunikacji niezbędnej do uczynienia tego dobrym procesem. Twój zespół będzie musiał komunikować się o kodzie, zmianach i ogólnie o statusie projektu.

Innym wymiarem w kontekście dyscypliny jest zachęcanie do rozgałęziania i eksperymentów. Oto cytat z ostatniego wpisu w bliki Martina Fowlera na temat narzędzi kontroli wersji . Znalazł on bardzo zwięzły opis tego zjawiska.

DVCS zachęca do szybkiego rozgałęziania w celu eksperymentowania. Możesz tworzyć gałęzie w Subversion, ale fakt, że są one widoczne dla wszystkich, zniechęca ludzi do otwierania gałęzi do pracy eksperymentalnej. Podobnie DVCS zachęca do sprawdzania pracy: wprowadzania niekompletnych zmian, które mogą nawet nie skompilować lub nie przejść testów, do lokalnego repozytorium. Ponownie możesz to zrobić w gałęzi programisty w Subversion, ale fakt, że takie gałęzie znajdują się we wspólnej przestrzeni, zmniejsza prawdopodobieństwo, że ludzie to zrobią.

DVCS umożliwia elastyczne przepływy pracy, ponieważ zapewniają śledzenie zestawu zmian za pomocą globalnie unikalnych identyfikatorów na skierowanym acyklicznym grafie (DAG) zamiast prostych tekstowych różnic. Pozwala im to na przejrzyste śledzenie pochodzenia i historii zbioru zmian, co może być bardzo ważne.

Przepływy pracy:

Larry Osterman (deweloper Microsoftu pracujący w zespole Windows) ma świetny wpis na blogu dotyczący przepływu pracy, który stosują w zespole Windows. Przede wszystkim mają:

• Czysty, wysokiej jakości bagażnik zawierający tylko kod (repozytorium główne)
• Cały rozwój odbywa się na gałęziach funkcji
• Zespoły funkcyjne mają repozytoria zespołów
• Regularnie łączą najnowsze zmiany linii głównej w swojej gałęzi funkcji ( Forward Integrate )
• Pełne funkcje muszą przejść kilka bramek jakości, np. Przegląd, pokrycie testów, pytania i odpowiedzi (same repozytoria)
• Jeśli funkcja jest ukończona i ma akceptowalną jakość, jest scalana z magistralą ( Reverse Integrate )

Jak widać, mając osobne repozytoria, możesz oddzielić różne zespoły postępujące w różnym tempie. Również możliwość wdrożenia elastycznego systemu bramek jakości odróżnia DVCS od CVCS. Na tym poziomie również możesz rozwiązać swoje problemy z uprawnieniami. Tylko garstka osób powinna mieć dostęp do głównego repozytorium. Dla każdego poziomu hierarchii przygotuj oddzielne repozytorium z odpowiednimi zasadami dostępu. Rzeczywiście, takie podejście może być bardzo elastyczne na poziomie zespołu. Powinieneś pozostawić każdemu zespołowi decyzję, czy chcą podzielić się swoim repozytorium zespołu między sobą, czy też chcą bardziej hierarchicznego podejścia, w którym tylko lider zespołu może zaangażować się w repozytorium zespołu.

(Zdjęcie zostało skradzione z hginit.com Joela Spolsky'ego ).

W tym miejscu pozostaje jednak do powiedzenia jedna rzecz: - mimo że DVCS zapewnia doskonałe możliwości łączenia, nigdy nie zastępuje korzystania z Continuous Integration. Nawet w tym momencie masz dużą elastyczność: CI dla repozytorium trunk, CI dla repozytoriów zespołowych, repozytorium pytań i odpowiedzi itp.

Git w kontekście przedsiębiorstwa:

Git może nie jest idealnym rozwiązaniem dla kontekstu korporacyjnego, jak już zauważyłeś. Powtarzając niektóre z twoich obaw, myślę, że w szczególności są to:

• Wciąż nieco niedojrzałe wsparcie w systemie Windows (proszę poprawić mnie, jeśli to się ostatnio zmieniło) Teraz system Windows ma klienta Windows github , tortoisegit , SourceTree z atlassian
• Brak dojrzałych narzędzi GUI, brak integracji narzędzia vdiff / merge dla obywateli pierwszej klasy
• Niespójny interfejs z bardzo niskim poziomem abstrakcji poza jego wewnętrznym działaniem
• Bardzo stroma krzywa uczenia się dla użytkowników svn
• Git jest bardzo potężny i sprawia, że ​​jest to łatwe do modyfikacji historię, bardzo niebezpieczne, jeśli nie wiesz, co robisz (a czasami nawet jeśli myślałeś, że wiedział)
• Brak dostępnych opcji pomocy technicznej

Nie chcę tutaj zaczynać flamewar git vs. hg, wykonałeś już właściwy krok, przechodząc na DVCS. Mercurial odnosi się do niektórych z powyższych punktów i myślę, że w związku z tym jest lepiej dopasowany do kontekstu przedsiębiorstwa:

• Obsługiwane są wszystkie platformy obsługujące język Python
• Świetne narzędzia GUI na wszystkich głównych platformach (win / linux / OS X), pierwszorzędna integracja narzędzi scalających / vdiff
• Bardzo spójny interfejs, łatwe przejście dla użytkowników svn
• Potrafi większość rzeczy, które potrafi również git, ale zapewnia czystszą abstrakcję. Niebezpieczne operacje są zawsze jednoznaczne. Zaawansowane funkcje są udostępniane za pośrednictwem rozszerzeń, które muszą być jawnie włączone.
• Wsparcie komercyjne jest dostępne w firmie Selenic.

Krótko mówiąc, używając DVCS w przedsiębiorstwie, uważam, że ważne jest, aby wybrać narzędzie, które wprowadza jak najmniej tarcia. Aby przejście zakończyło się sukcesem, szczególnie ważne jest, aby wziąć pod uwagę różne umiejętności między programistami (w odniesieniu do VCS).

Zmniejszenie tarcia:

Ok, ponieważ wydaje się, że naprawdę utknąłeś w tej sytuacji, pozostały dwie opcje IMHO. Nie ma narzędzia, które mogłoby uczynić git mniej skomplikowanym; git jest skomplikowany. Albo skonfrontujesz się z tym, albo obejdziesz git: -

1. Weź udział w kursie wprowadzającym do git dla całego zespołu. Powinno to obejmować tylko podstawy i kilka ćwiczeń (ważne!).
2. Przekonwertuj repozytorium główne na svn i pozwól „młodym gwiazdom” git-svn . Zapewnia to większości programistów łatwy w użyciu interfejs i może zrekompensować brak dyscypliny w zespole, podczas gdy młode gwiazdy mogą nadal używać gita do własnych repozytoriów.

Szczerze mówiąc, myślę, że naprawdę masz problem z ludźmi, a nie z narzędziami. Co można zrobić, aby poprawić tę sytuację?

• Powinieneś jasno powiedzieć, że myślisz, że Twój obecny proces zakończy się bazą kodu, którą można utrzymać.
• Zainwestuj trochę czasu w ciągłą integrację. Jak nakreśliłem powyżej, niezależnie od tego, jakiego rodzaju VCS używasz, CI nigdy nie zastąpi. Stwierdziłeś, że są ludzie, którzy wpychają bzdury do głównego repozytorium: niech naprawią swoje bzdury, gdy włączy się czerwony alert i obwinią ich za zerwanie kompilacji (lub niespełnienie miernika jakości lub cokolwiek innego).

Jestem inżynierem SCM w dość dużej organizacji programistycznej i przeszliśmy na git z svn w ciągu ostatniego roku. Używamy go w sposób scentralizowany.

Używamy gitosis do hostowania repozytoriów. Podzieliliśmy nasze monolityczne repozytoria svn na wiele mniejszych repozytoriów git, ponieważ jednostka rozgałęziająca gita jest w zasadzie repozytorium. (Są sposoby na obejście tego, ale są niewygodne). Jeśli potrzebujesz kontroli dostępu dla poszczególnych gałęzi, lepszym rozwiązaniem może być gitolite . Istnieje również wersja GitHub wewnątrz zapory ogniowej, jeśli chcesz wydać pieniądze. Dla naszych celów gitoza jest w porządku, ponieważ mamy dość otwarte uprawnienia do naszych repozytoriów. (Mamy grupy ludzi, którzy mają prawa zapisu do grup repozytoriów i każdy ma prawo odczytu do wszystkich repozytoriów.) Używamy gitweb jako interfejsu WWW.

Jeśli chodzi o niektóre z twoich konkretnych obaw:

• scalanie: Możesz użyć dowolnego narzędzia do wizualnego scalania; w różnych miejscach są instrukcje, jak to skonfigurować. Fakt, że możesz dokonać scalenia i sprawdzić jego poprawność całkowicie w swoim lokalnym repozytorium, jest moim zdaniem dużym plusem dla git; możesz zweryfikować połączenie, zanim cokolwiek wrzucisz.
• GUI: Mamy kilka osób używających TortoiseGit, ale nie polecam go; wydaje się, że w dziwny sposób wchodzi w interakcje z wierszem poleceń. Muszę się zgodzić, że jest to obszar wymagający poprawy. (To powiedziawszy, nie jestem fanem GUI do kontroli wersji w ogóle.)
• Małe gałęzie śledzenia: jeśli używasz czegoś, co zapewnia bardziej szczegółowe listy ACL, takie jak gitolite, łatwo to zrobić, ale możesz również utworzyć wspólną gałąź, łącząc lokalne repozytoria różnych programistów - repozytorium git może mieć wiele pilotów.

Przerzuciliśmy się na git, ponieważ mamy wielu zdalnych programistów i ponieważ mieliśmy wiele problemów z Subversion. Wciąż eksperymentujemy z przepływami pracy, ale w tej chwili zasadniczo używamy ich w taki sam sposób, w jaki używaliśmy Subversion. Inną rzeczą, która nam się spodobała, było to, że otworzyło inne możliwe przepływy pracy, takie jak użycie repozytoriów pomostowych do przeglądu kodu i udostępniania go małym grupom. Zachęciło to również wiele osób do rozpoczęcia śledzenia swoich osobistych skryptów i tak dalej, ponieważ tak łatwo jest utworzyć repozytorium.

Tak, wiem, Linus nigdy tego nie zamierzał.

Właściwie Linus twierdzi, że scentralizowane systemy po prostu nie mogą działać.

A co jest nie tak z przepływem pracy dyktatora i poruczników?

Pamiętaj, git jest dystrybuowany system ; nie próbuj używać go jako centralnego.

(zaktualizowany)

Większość problemów zniknie, jeśli nie spróbujesz używać gita tak, jakby był to „svn on steroid” (ponieważ tak nie jest).

Zamiast używać czystego repozytorium jako centralnego serwera, na którym każdy może przesyłać dane (i potencjalnie zepsuć), skonfiguruj kilku menedżerów integracji obsługujących scalenia, tak aby tylko oni mogli przesyłać dane do samego repozytorium.

Zwykle ci ludzie powinni być liderami zespołu: każdy lider integruje pracę własnego zespołu i przenosi ją do błogosławionego repozytorium.

Co więcej, ktoś inny (tj. Dyktator) wyciąga od liderów zespołów i integruje ich zmiany w błogosławionym repozytorium.

Nie ma nic złego w tym przepływie pracy, ale jesteśmy przepracowanym startupem i potrzebujemy naszych narzędzi, aby zastąpić ludzki czas i uwagę; nikt nie ma wystarczającej przepustowości, aby nawet dokonywać recenzji kodu, nie mówiąc już o byciu życzliwym dyktatorem.

Jeśli integratorzy nie mają czasu na przeglądanie kodu, to dobrze, ale nadal potrzebujesz ludzi, którzy integrują fuzje od wszystkich.

Wykonywanie git pullsów nie zajmuje dużo czasu.

git pull A
git pull B
git pull C

git ma substytutu dla ludzkiego czasu i uwagi; dlatego został napisany w pierwszej kolejności.

• Narzędzia GUI nie są dojrzałe

Narzędzia gui całkiem dobrze radzą sobie z podstawowymi rzeczami.

Zaawansowane operacje wymagają nastawienia kodera / nerdy (np. Czuję się komfortowo, pracując z wiersza poleceń). Zrozumienie koncepcji zajmuje trochę czasu, ale nie jest to takie trudne.

• Korzystając z narzędzi wiersza poleceń, bardzo łatwo jest zepsuć scalanie i zatrzeć czyjeś zmiany

Nie będzie to problemem, chyba że masz wielu niekompetentnych programistów z pełnym dostępem do zapisu w „centralnym repozytorium”.

Ale jeśli skonfigurujesz swój przepływ pracy tak, że tylko kilka osób (integratorów) będzie pisać do „błogosławionego” repozytorium, nie będzie to problemem.

Git nie ułatwia zepsucia połączeń.

W przypadku konfliktów scalania git wyraźnie zaznaczy sprzeczne linie, abyś wiedział, które zmiany są twoje, a które nie.

Łatwo jest również wymazać kod innych osób za pomocą svn lub dowolnego innego (nieodpisanego) narzędzia. W rzeczywistości jest to o wiele łatwiejsze w przypadku tych innych narzędzi, ponieważ masz tendencję do „siedzenia na zmianach” przez długi czas, a w pewnym momencie scalanie może stać się strasznie trudne.

A ponieważ te narzędzia nie wiedzą, jak scalić, zawsze musisz scalać elementy ręcznie. Na przykład, gdy tylko ktoś zatwierdzi plik, który edytujesz lokalnie, zostanie to oznaczone jako konflikt, który należy rozwiązać ręcznie; teraz to jest koszmar utrzymanie.

Dzięki git przez większość czasu nie będzie żadnych konfliktów przy scalaniu, ponieważ git faktycznie może się scalić. W przypadku, gdy wystąpi konflikt, git wyraźnie oznaczy linie za Ciebie, abyś dokładnie wiedział , które zmiany są twoje, a które od innych osób.

Jeśli ktoś zatrze zmiany innych ludzi podczas rozwiązywania konfliktu scalającego, nie będzie to przypadek: albo dlatego, że było to konieczne do rozwiązania konfliktu, albo dlatego, że nie wiedzą, co robią.

• Nie oferuje uprawnień repozytorium dla każdego użytkownika poza globalnymi uprawnieniami tylko do odczytu lub odczytu i zapisu

• Jeśli masz pozwolenie na DOWOLNĄ część repozytorium, możesz zrobić to samo z KAŻDĄ częścią repozytorium, więc nie możesz zrobić czegoś takiego, jak utworzenie gałęzi śledzenia małej grupy na serwerze centralnym, czego inni ludzie nie mogą zadzierać z.

• Przepływy pracy inne niż „wszystko idzie” lub „życzliwy dyktator” są trudne do zachęcania, nie mówiąc już o egzekwowaniu

Te problemy znikną, gdy przestaniesz używać git tak, jakby był to scentralizowany system.

• Nie jest jasne, czy lepiej jest używać jednego dużego repozytorium (które pozwala wszystkim majstrować we wszystkim), czy wielu repozytoriów dla poszczególnych komponentów (co powoduje ból głowy przy próbie synchronizacji wersji).

Wezwanie do sądu.

Jakie masz projekty?

Na przykład: czy wersja xy projektu A zależy dokładnie od wersji wz projektu B tak, że za każdym razem , gdy sprawdzasz xy projektu A, musisz również pobrać wz projektu B, w przeciwnym razie nie zostanie zbudowany? Gdyby tak było, umieściłbym zarówno projekt A, jak i projekt B w tym samym repozytorium, ponieważ są one oczywiście dwiema częściami jednego projektu.

Najlepszą praktyką jest użycie mózgu

• W przypadku wielu repozytoriów nie jest również jasne, jak replikować wszystkie źródła, które ktoś inny ma, wyciągając z centralnego repozytorium lub zrobić coś takiego, jak uzyskać wszystko od wczoraj o 4:30 po południu.

Nie jestem pewny co masz na myśli.

Bardzo polecam http://code.google.com/p/gerrit/ do pracy w przedsiębiorstwie. Zapewnia kontrolę dostępu oraz wbudowany przepływ pracy oparty na recenzjach. Uwierzytelnia się w każdym systemie LDAP. Możesz podłączyć go do Hudson za pomocą http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , umożliwiając tworzenie i testowanie zmian, gdy są jeszcze w trakcie sprawdzania; to naprawdę imponująca konfiguracja.

Jeśli zdecydujesz się użyć gerrita, polecam zachować dość liniową historię, a nie rozgałęzioną historię, jak lubią niektórzy faceci z open source. Gerrit określa to jako „zezwalaj tylko na szybkie zmiany”. Następnie możesz używać rozgałęziania i scalania w sposób bardziej podobny do tego, do jakiego jesteś przyzwyczajony, dla wydań i tak dalej.

Odpowiadam na to pytanie, opierając się na moim doświadczeniu jako menedżer programisty w dużej firmie telekomunikacyjnej, w której wdrożyliśmy Gita w 2010 roku

Masz tutaj całkiem inny zestaw problemów:

• przepływy pracy
• narzędzia klienta
• kontrola dostępu do serwera i integracja

Przepływy pracy

Z powodzeniem przyjęliśmy tryb centralnego repozytorium: to, co mamy w naszym projekcie korporacyjnym (duży portal dla 5 milionów użytkowników) to de facto centralne repozytorium, które tworzy oficjalne wersje, a następnie przechodzi przez proces dostawy (który w naszym przypadek składa się z trzech poziomów testowania i dwóch wdrożeń). Każdy programista zarządza swoim własnym repozytorium, a my pracujemy na zasadzie oddziału na funkcję.

Narzędzia klienta

Obecnie dostępnych jest kilka opcji, jest to teraz bardzo zatłoczony obszar. Wielu programistów z powodzeniem używa IntelliJ Idea i Eclipse z wtyczką Git , bez żadnych innych rzeczy. Ponadto większość programistów Linuksa używa klienta git CLI bez żadnego problemu. Niektórzy programiści komputerów Mac z powodzeniem używają Tower Git . Należy pamiętać, że żaden z tych klientów może zapobiec "bałaganowi" użytkownika w centralnym repozytorium: potrzebny jest mechanizm kontroli po stronie serwera

Kontrola dostępu do serwera i integracja

Jeśli chcesz uniknąć zepsucia przez programistów repozytorium Git, musisz wybrać rozwiązanie, które:

• udostępnia przyzwoity interfejs administratora sieci do wykonywania każdej operacji
• umożliwia wymuszanie tożsamości użytkowników (korzystanie z „czystego” repozytorium Git jest niezwykle łatwe do zatwierdzenia w imieniu innej osoby)
• zapewnia precyzyjne zabezpieczenia (na przykład można zapobiec FORCE-PUSH i ustawić niektóre gałęzie do odczytu tylko dla niektórych programistów / grup)
• zintegruj się z Twoim firmowym systemem uwierzytelniania (np. LDAP, Windows ActiveDirectory)
• zapewnia pełny audyt (zgodność z SOX jest czasami bardzo ważna dla dużych korporacji)

Nie ma zbyt wielu gotowych do użycia rozwiązań po stronie serwera, które mogą w tym pomóc, proponuję sprawdzić jedno z poniższych:

• Gitorious : może zapewnić podstawowe bezpieczeństwo na poziomie dostępu, ale nie ma precyzyjnej kontroli uprawnień po wyjęciu z pudełka, więc prawdopodobnie będziesz musiał wykonać pewne kodowanie, aby obsłużyć scenariusze, takie jak uprawnienia na poziomie gałęzi. Brakuje również integracji z istniejącymi korporacyjnymi mechanizmami uwierzytelniania
• GitHub Enterprise: niedawno opublikowane przez GitHub, zawiera GitHub w Twojej firmie. Brakuje zgodności z SOX i drobnoziarnistego bezpieczeństwa
• Gerrit : może zapewnić wysoki poziom bezpieczeństwa dostępu i integrację z korporacyjnymi systemami uwierzytelniania, ale brakuje mu zgodności z SOX i SSO. Ponadto niektóre operacje można wykonać tylko przez SSH przez CLI
• GitEnterprise : zapewnia uprawnienia na poziomie oddziału, SSO, zgodność z SOX, pełną administrację internetową. Niedawno został również zintegrowany z Gerrit, dzięki czemu zapewnia również pełną instancję Gerrit

Mam nadzieję że to pomoże!

Wygląda na to, że Twoim problemem jest to, że nie zdecydowałeś ani nie ustanowiłeś przepływu pracy. Git jest wystarczająco elastyczny, aby używać go jak svn lub innego VCS, ale jest tak potężny, że jeśli nie ustalisz zasad, których wszyscy muszą przestrzegać, skończysz z bałaganem. Poleciłbym przepływ pracy dyktator-porucznik, o którym ktoś wspomniał powyżej, ale w połączeniu z modelem rozgałęzień opisanym przez Vincenta Driessena . Aby uzyskać więcej informacji, zobacz te screencasty autorstwa Davida Bocka , a ten autorstwa Marka Derricutta .

Użytkownicy MacOS-X uważają, że narzędzia GitX (http://gitx.frim.nl/) są bardzo proste i skuteczne. Wadą jest to, że nie obsługuje hooków klienta Git (tych pod $ GIT_ROOT / .git / hooks).

Ogólnie rzecz biorąc, zdecydowanie staram się wybrać narzędzie, które obsługuje precyzyjną kontrolę dostępu do: - oddziałów (w celu oddzielenia gałęzi stabilnego wydania ze ścisłym zabezpieczeniem od gałęzi tematycznych, które wymagają większej sprawności i elastyczności) - egzekwowania tożsamości (autor / autor ). To jest KEY for SOX - ograniczenia poleceń git - ścieżka audytu. To jest KLUCZ dla SOX

Te, których z powodzeniem używałem z tymi funkcjami, to:

1. Przegląd kodu Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), używa Gerrit 2.1.8 za kulisami

PS Nie lekceważ zgodności z SOX i CMMI : często masz ograniczony wybór, który jest podyktowany zasadami przedsiębiorstwa dotyczącymi bezpieczeństwa.

Mam nadzieję że to pomoże.

Luca.

Niedawno przerzuciliśmy się z svn na git. Ponieważ git-daemon nie działa z msysgit, zdecydowaliśmy się na centralne repozytorium na serwerze Linux z gitosis.

Aby wyeliminować możliwość zepsucia mastera, po prostu go usunęliśmy. Zamiast tego przygotowujemy wszystkie wydania, scalając gałęzie wybrane do testowania i tagując scalanie. Jeśli przejdzie testy, zatwierdzenie jest oznaczane wersją i umieszczane w produkcji.

Aby sobie z tym poradzić, mamy rotacyjną rolę menedżera wersji. Menedżer wydania jest odpowiedzialny za sprawdzenie każdej gałęzi, zanim będzie ona gotowa do testów. Następnie, gdy właściciel produktu zdecyduje, że nadszedł czas, aby zebrać razem zatwierdzone gałęzie w celu wydania nowej wersji testowej, menedżer wersji przeprowadza scalanie.

Mamy również rotacyjną rolę działu pomocy technicznej drugiego stopnia i przynajmniej dla nas obciążenie pracą jest takie, że możliwe jest pełnienie obu ról jednocześnie.

Korzyścią wynikającą z braku mastera jest to, że nie można dodać żadnego kodu do projektu bez przejścia przez menedżera wydania, więc bezpośrednio odkryliśmy, ile kodu zostało wcześniej po cichu dodane do projektu.

Proces recenzji rozpoczyna się od przesłania przez właściciela oddziału różnicy na tablicę recenzencką i umieszczenia na tablicy zielonej kartki samoprzylepnej z nazwą oddziału (mamy przepływ pracy oparty na Kanban) pod „do przeglądu” lub jeśli jest to część ukończonego użytkownika story, przenieś całą kartę opowieści do „do przejrzenia” i umieść tam post. Menedżer wydania to ten, który przenosi karty i karteczki do „gotowego do testowania”, a następnie właściciel produktu może wybrać, które z nich mają zostać wprowadzone w następnej wersji testowej.

Podczas scalania menedżer wydania upewnia się również, że zatwierdzenie scalające zawiera sensowny komunikat o zatwierdzeniu, który może być użyty w dzienniku zmian dla właściciela produktu.

Po wprowadzeniu wydania do produkcji tag jest używany jako nowa baza dla oddziałów, a wszystkie istniejące gałęzie są z nim łączone. W ten sposób wszystkie gałęzie mają wspólnego rodzica, co ułatwia obsługę połączeń.

Dodam też wpis „Czy rozważałeś”.

Jedną z największych zalet Bazaar jest jego elastyczność. W tym miejscu bije wszystkie inne systemy rozproszone. Możesz obsługiwać Bazar w trybie scentralizowanym, rozproszonym lub uzyskać jedno i drugie (co oznacza, że ​​programiści mogą wybrać model, z którym czują się komfortowo lub który działa najlepiej dla ich grupy roboczej). Możesz także odłączyć scentralizowane repozytorium podczas podróży i ponownie je połączyć, gdy wrócisz.

Do tego doskonała dokumentacja i coś, co uszczęśliwi Twoje przedsiębiorstwo: dostępne wsparcie komercyjne.

• Zainstaluj przyzwoity interfejs internetowy, taki jak Github FI
• Trzymaj się stosunkowo scentralizowanego modelu (początkowo), aby zapewnić ludziom komfort.
• Uruchom kompilację ciągłej integracji dla każdej udostępnionej gałęzi.
• Udostępnij dobry zestaw globalnych opcji konfiguracyjnych git.
• Zintegruj git ze swoją powłoką, z uzupełnianiem bash i monitem o bieżącą gałąź.
• Wypróbuj integrację Git firmy IntelliJ jako narzędzie do scalania.
• Upewnij się, że masz .gitignore odpowiednio.

Odnośnie punktów 3 i 4 (uprawnienia dla użytkownika, dla sekcji, dla gałęzi), spójrz na gitolite (omówione w książce Pro Git: http://progit.org/book/ch4-8.html ).

Polityka czy nie, Git jest równie dobrym wyborem DCVS, jak każdy inny. Jak każde potężne narzędzie, warto poświęcić trochę czasu na zrozumienie, jak to narzędzie jest zaprojektowane do działania, i w tym celu gorąco polecam książkę o Pro Git. Kilka godzin spędzonych z nim zaoszczędzi na dłuższą metę wielu frustracji.

GUI: W tej chwili TortoiseGit v1.7.6 powinien być odpowiedni dla większości codziennych operacji. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc ... Obsługuje również natywnie x64

Aby efektywnie używać git w zespole programistycznym składającym się z wielu programistów, wymagany jest system CI, który stale buduje i testuje. Jenkins zapewnia taki pojazd i bardzo go polecam. Integrację trzeba zrobić bez względu na wszystko i dużo taniej jest robić to wcześniej i częściej.

Bardziej nadaje się do rozwoju zespołowego niż gitosis czy gitolite, ale open-source to Gitorious . Jest to aplikacja Ruby on Rails, która obsługuje zarządzanie repozytoriami i łączenie. Powinien rozwiązać wiele twoich problemów.

Git umożliwia tworzenie oddziałów prywatnych. Zachęca to programistów do częstego zatwierdzania, aby rozbić modyfikacje na małe zatwierdzenia. Gdy programista jest gotowy do opublikowania swoich zmian, wypycha na centralny serwer. W razie potrzeby może skorzystać ze skryptów pre-commit, aby zweryfikować swój kod.

NXP zarządza Git i Subversion za pomocą jednej wspólnej platformy (w skali przedsiębiorstwa), integrując tworzenie aplikacji mobilnych na Androida z tradycyjnymi projektami oprogramowania: http://www.youtube.com/watch?v=QX5wn0igv7Q