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.
źródło
a process
... (nienawidzę tego słowa)Odpowiedzi:
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 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ą:
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 atlassianNie 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:
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: -
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ę?
źródło
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:
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.
źródło
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.
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 ma substytutu dla ludzkiego czasu i uwagi; dlatego został napisany w pierwszej kolejności.
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.
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ą.
Te problemy znikną, gdy przestaniesz używać git tak, jakby był to scentralizowany system.
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
Nie jestem pewny co masz na myśli.
źródło
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.
źródło
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
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:
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:
Mam nadzieję że to pomoże!
źródło
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 .
źródło
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:
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.
źródło
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ń.
źródło
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.
źródło
źródło
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.
źródło
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
źródło
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.
źródło
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.
źródło
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.
źródło
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
źródło