Jakiej kontroli źródła potrzebuję dla dużego projektu w przeciętnej firmie? [Zamknięte]

10

Wiem, że Git jest świetny do projektów typu open source. Zastanawiałem się jednak: dla firmy z 20 programistami pracującymi nad rocznym projektem, który system kontroli źródła jest pożądany? Z tego, co słyszałem, Git używa ciągnięcia; czy nie byłoby pożądane, aby przejść przez kogoś innego, aby uzyskać zmiany w głównym bagażniku? Zwłaszcza, gdy wszyscy pracują w tym samym czasie?

To tylko przykład, nad którym się zastanawiałem. Wiem, jak korzystać z SVN, ale nawet przy mojej ostatniej pracy nie korzystaliśmy z niego w naszych projektach, ponieważ wszystko zostało zrobione w PHP i były to zwykle samodzielne projekty 1-tygodniowe. Właśnie miałem SVN dla mojego lokalnego kodu i nie musiałem go używać z innymi.

Więc jakie są dobre kontrole źródeł, a konkretnie dlaczego to jest dobre?

Martin Maat
źródło
13
Ponieważ kodowanie w php nie jest powodem, aby nie używać VCS.
Chris,
@Chris: Gdyby to zależało ode mnie, w sieci byłoby repo. Ale niestety ta firma w ogóle go nie wykorzystała. Mówiłem tylko, że nie mam doświadczenia w pracy zespołowej z kontrolą źródła

Odpowiedzi:

29

Używaj tego, z czym czuje się twój zespół. Wszystkie systemy kontroli wersji robią mniej więcej to samo w podobny sposób; nie ma powodu, by wymyślać na nowo koło, ponieważ „może działać lepiej”. Jeśli twój zespół nie czuje się komfortowo z czymkolwiek, wybierz opcję, która ma najłatwiejszą integrację ze standardowym IDE twojego zespołu.

EricBoersma
źródło
1
To mądra i bezstronna odpowiedź - lubię.
Murph,
1
Systemy kontroli źródła +1 są wystarczająco złożone, wszystko, co możesz zrobić, aby to zminimalizować, będzie na lepsze!
Dal
3
Są rzeczy, które rozproszone VCS działają znacznie lepiej niż scentralizowane, i zawsze możesz używać DVCS jako scentralizowanego, więc do długoterminowego użytku ogólnego polecam Git lub Mercurial. W takich sytuacjach jakikolwiek nowoczesny VCS da sobie radę, a Subversion jest prawdopodobnie najłatwiejszy do nauczenia się.
David Thornley,
Zdecydowanie używaj tego, co Twój zespół wie lub jest wygodny w użyciu. (Chyba że jest to CVS lub RCS.) Jeśli przejdziesz na coś nowego i każdy musi się tego nauczyć, zrób matematykę: 20 osób * 3 godziny treningu * 40 USD / godzinę = 2400 USD.
Barry Brown
Lub oczekuj, że będą wiedzieć, jak kompetentnie wybrać nowy VCS w ciągu 5 minut ...
alternatywnie
4

Mercurial jest doskonały, rozproszony i bezpłatny.

Steven A. Lowe
źródło
4

Myślę, że to zależy od tego, jakiego poziomu wsparcia potrzebujesz.

Używam git w domu do swoich fajnych projektów, gdy problem kosztuje mnie czas, ale mogę poświęcić czas na naukę, co muszę naprawić.

W pracy korzystamy z Perforce, ponieważ niezbędne jest wsparcie techniczne 24/7. Cały czas pracujemy nad kodem w Nowym Jorku, Niemczech, Irlandii i Japonii. Jeśli występuje problem, musimy jak najszybciej uzyskać odpowiedź. Z mojego doświadczenia wynika, że ​​ludzie w Perforce naprawdę wiedzą, co robią i są otwarci na sugestie.

Mark Thalman
źródło
1
+1: Perforce jest drogi, ale dostajesz to, za co płacisz.
Nikt
3

Chociaż uważam, że to pytanie jest szerokie i powinno dotyczyć poszczególnych firm, w oparciu o ramy IT i struktury sieci / rozwoju, uważam, że najważniejszym aspektem wyboru źródła / kontroli wersji nie jest to, z której aplikacji korzystasz, ale czy korzystanie z niego jest praktycznie ustrukturyzowane i egzekwowane.

Struktura i egzekwowanie użycia są najważniejszymi aspektami kontroli wersji.

Planuj z wyprzedzeniem i weź wszystkich na pokład. Wymuszaj użycie. Nie tylko z programistami, ale ze wszystkim, co dotyczy projektów (dokumenty, obrazy itp.).

SVN to świetna aplikacja, którą można zintegrować z wieloma dodatkami (w tym śledzenie błędów / zadań), nie wymaga osobnego serwera i jest bezpłatny!

Istnieją również inne dobre aplikacje do kontroli źródła, jak powiedział @EricBoersma:

Używaj tego, z czym czuje się twój zespół.

Wystarczy wdrożyć procesy i najlepsze praktyki i odkupić się od tych, które mogą je egzekwować.

Paige Watson
źródło
3

Masz poważne nieporozumienia na temat działania git. Wysłanie żądania ściągnięcia do strażnika jest tylko jednym ze sposobów. Istnieje wiele innych sposobów konfiguracji, w tym prawie tak samo jak svn, czyli dokładnie tyle osób, które zaczynają, zanim poczują się wystarczająco wygodnie, aby je dostosować. W przypadku DVCS, takich jak git, masz wystarczająco dużo opcji, aby uporządkować kontrolę źródła na podstawie przepływu pracy, a nie na odwrót.

Karl Bielefeldt
źródło
2

Kiedyś uważałem, że kontrola źródła jest tylko narzędziem i że każdy z produktów działa mniej więcej tak samo. I wtedy punkt tych rozproszonych systemów kontroli wersji kliknął ze mną.

Rozproszona kontrola wersji pozwala mieć więcej niż jedno centralne repozytorium. Wyobraź sobie zmiany kodu migrujące z lokalnego repozytorium programisty, do repozytorium funkcji, do repozytorium produktu, do repozytorium kontroli jakości i wreszcie do zwolnionego repozytorium.

Osobiście używam komercyjnego produktu o nazwie Kiln, który jest oparty na Hg, ale kluczową funkcją jest rozproszona kontrola wersji . Rewolucjonizuje przepływ nowego kodu od dewelopera do wydanego produktu.

Michael Shaw
źródło
To mnóstwo repozytoriów dla jednego projektu. Co za koszmar dla połączenia.
JBRWilkinson
3
Zgodziłbym się z Tobą, gdyby łączył się z SubVersion lub CVS. Powodem, dla którego działają te rozproszone produkty kontroli wersji, jest to, że sprawiają, że scalanie jest proste i w dużej mierze wolne od konfliktów.
Michael Shaw
2

Wiesz, jak używać SVN, a następnie SVN - migruj do DVCS tylko wtedy, gdy jest w nich coś, czego potrzebujesz.

To, co jest naprawdę ważne, to korzystanie z czegoś, co lubisz, a które jest łatwe w użyciu. Martin Fowler przeprowadził szybką i prostą ankietę na temat VCS, wyniki są bardzo interesujące.

gbjbaanb
źródło
2

Skonfigurowałem git na mojej ostatniej pracy, w której pracowaliśmy nad projektem podobnej wielkości (15 programistów, projekt 18-miesięczny) i działało to dobrze.

Sposób, w jaki to skonfigurowaliśmy, to:

Mieliśmy serwer git, który był naszym scentralizowanym, autorytatywnym serwerem git. Członkowie zespołu byli zniechęcani do ściągania od siebie bezpośrednio, aby wszystkie zmiany przeszły na centralny serwer.

Używaliśmy gałęzi master jako głównej gałęzi produkcji, z tagami dla każdej wersji. Każdy moduł w projekcie był podmodułem git. Każdy podmoduł miał gałęzie dla każdego członka zespołu. Opiekun (zwykle pierwotny autor) został przypisany do każdego podmodułu i byli oni odpowiedzialni za obsługę żądań ściągania od innych członków zespołu oraz za wysyłanie żądań ściągania do kierownika zespołu, który aktualizowałby submoduł w głównym oddziale, gdy był gotowy do być zintegrowanym z branżą produkcyjną. Użyliśmy tagów do zidentyfikowania zatwierdzeń, które zakończyły określoną funkcję lub które odpowiadały wydaniu.

Cercerilla
źródło
0

Chciałbym dać Team Foundation System (TFS) od Microsoft przynajmniej dobry wygląd. Biorę to z twoich komentarzy, że nie jesteś sklepem Microsoft. Rozumiem jednak, że jeśli używasz tego IDE do programowania, masz dość solidną wtyczkę Eclipse.

Mechanizmy łączenia i rozgałęziania działają tak samo dobrze, jak każdy inny system kontroli źródła (według mojego doświadczenia lepszy niż svn i mniej więcej tak dobry jak perforce), ale tak naprawdę wyróżnia się śledzenie projektu i aspekty zarządzania projektem produktu oraz wbudowana automatyzacja kompilacji i wdrożeń.

Jeśli piszesz aplikację internetową, zapoznaj się ze strukturą automatycznego testowania interfejsu użytkownika oraz ramą testowania obciążenia, którą możesz zbudować i skonfigurować w dość krótkim czasie. Jedna elegancka funkcja: symulowanie przeglądarek mobilnych wbudowanych w test obciążenia.

As w dziurze
źródło
Mówiąc jak ktoś, kto używał TFS z Eclipse. Nie, to okropne. (mogę przejść do szczegółów), zdecydowanie nie nazwałbym tego solidnym. TFS jest świetny, ale rozszerzenie Eclipse jest szokująco złe (gdzie świetny jest AnhkSVN dla Visual Studio)
Lyndon White
Mam bardzo złe doświadczenia z TFS z wielu powodów, chociaż pracuję w środowisku Microsoft i lubię narzędzia .Net i Ms w ogóle. Nigdy nikomu nie będę polecał TFS.
AFract