Przedstawiłem Git zespołowi deweloperów i wszyscy go nienawidzą oprócz mnie. Chcą go zastąpić Team Foundation Server. Wydaje mi się, że jest to ogromny krok wstecz, choć nie znam się dobrze na TFS. Czy ktoś z doświadczeniem może porównać obsługę rozgałęziania w TFS z rozgałęzianiem Git? Poza tym, jakie są zalety i wady TFS? Czy nienawidzę tego po kilku latach używania Git?
Stajesz w tej bitwie pod górę. Git nie jest tak dojrzały, jak svn / hg / tfs w systemie Windows, co nie przeszkadza weteranom, ale stanowi poważny problem dla początkujących.
Marcelo Cantos,
7
@Jacko: W ostatnich tygodniach testowałem git-for-Windows. Chociaż znacznie się poprawił od czasu, gdy ostatni raz go obejrzałem około rok temu, wciąż jest daleka droga do przygotowania się na świetny czas z typowymi programistami Windows. Np. Wtyczka VS jest szczerze godna pożałowania. To tylko garść opcji menu pod głównym paskiem menu, które cicho zawodzą, jeśli zamiast projektu wybrano rozwiązanie. Nie mogę uzyskać narzędzia zatwierdzania do indeksowania kawałków i linii, co jest głównym powodem, dla którego używam git, a dostanie się do git gui (co jest kompletnym okrucieństwem z POV użyteczności) jest w najlepszym razie niezręczne.
Marcelo Cantos,
6
Będę z tobą szczery; zabija mnie, by upuścić gita. W przeciwieństwie do popularnego poglądu, że oba są na równi, uważam, że model gita jest znacznie potężniejszy i logiczny. Mercurial nie ma nic wspólnego z indeksem gita i nienawidzę jego podejścia do rozgałęziania. Koncepcja etykiet Git, które można przenosić i synchronizować między repozytoriami, jest bardzo elegancka. Zakładki Mercurial są jedyną rzeczą, która się zbliża i są PITA dla wszystkich. Najważniejsze jest jednak to, że sukces jest bardziej prawdopodobny w przypadku svn → Mercurial niż svn → git, biorąc pod uwagę personel i względną dojrzałość narzędzi.
Marcelo Cantos,
4
tak, Git rządzi mocą i elegancją. Ale nie wszyscy są na to gotowi.
Jacko,
7
@JamesReategui: Osobiście uważam ( stackoverflow.com/a/11362998/520162 ), że integracja VCS w IDE to meander. Wyobraź sobie, że jutro zmienisz główne IDE. Co się stanie, jeśli upuścisz VS dla Eclipse? Czy naprawdę chcesz nauczyć się nowej integracji VCS? Git jest świetny w linii poleceń ( stackoverflow.com/a/5645910/520162 ). Naucz się go, a odkryjesz niesamowicie potężny świat kontroli wersji.
eckes
Odpowiedzi:
272
Myślę, że oświadczenie
wszyscy tego nienawidzą oprócz mnie
marnuje wszelkie dalsze dyskusje: gdy będziesz nadal używać Git, obwinią cię, jeśli coś pójdzie nie tak.
Poza tym Git ma dla mnie dwie zalety w stosunku do scentralizowanego VCS, które najbardziej doceniam (jak częściowo opisał Rob Sobers ):
automatyczne tworzenie kopii zapasowych całego repozytorium: za każdym razem, gdy ktoś wyciąga z repozytorium centralnego, otrzymuje pełną historię zmian. Gdy jedno repozytorium zaginie: nie martw się, weź jedną z obecnych na każdym stanowisku roboczym.
dostęp do repozytorium offline: kiedy pracuję w domu (lub w samolocie lub pociągu), mogę zobaczyć pełną historię projektu, każde pojedyncze zameldowanie, bez uruchamiania połączenia VPN do pracy i mogę pracować tak, jakbym był w pracy : zameldowanie, kasa, oddział, cokolwiek.
Ale jak powiedziałem: myślę, że stoczysz przegraną bitwę: kiedy wszyscy nienawidzą Gita, nie używaj Gita. Może ci to pomóc dowiedzieć się, dlaczego nienawidzą Gita, zamiast próbować ich przekonać.
Jeśli po prostu tego nie chcą, bo to dla nich nowość i nie chcą nauczyć się czegoś nowego: czy jesteś pewien, że uda ci się z powodzeniem opracować ten zespół?
Czy naprawdę każda osoba nienawidzi Gita, czy ma na nią wpływ niektórzy przywódcy opinii? Znajdź liderów i zapytaj ich, w czym problem. Przekonaj ich, a przekonasz resztę zespołu.
Jeśli nie możesz przekonać liderów: zapomnij o użyciu Git, weź TFS. Ułatwi ci życie.
Uderz, eckes. Obwiniają mnie za każdym razem, gdy coś idzie nie tak. Nie za to, że nie dowiedzieli się, jak to działa. Dla mnie Git jest tak blisko perfekcji, jak kiedykolwiek doświadczyłem w systemie kontroli wersji.
Jacko,
15
Z drugiej strony TFS obejmuje śledzenie wad / elementów roboczych, raportowanie ... i inne funkcje. Więc Git vs TFS tylko w funkcji VCS raczej nie ma sensu TFS.
Richard
5
@Dan see rebase, filter-tree ...
Artefacto
7
@Artefacto Wiem, ale potem wszystkie tagi zatwierdzenia zmieniają się, a wszystkie metadane (dyskusje na temat przeglądu kodu itp.) Są osierocone lub wymagają aktualizacji. Niemniej jednak miesiąc z TFS przekonał mnie, że nie ma go w lidze Gita jako system kontroli wersji. Git uwalnia programistę od produktywności w sposób, którego należy doświadczyć, aby go zrozumieć. Gałąź, jako metafora scratch padu, jest wyjątkowo potężna.
Dan Solovay
6
@Richard Twierdziłbym, że jest to wada TFS: kiedy już jesteś, jesteś w środku. Robi wszystko przeciętnie i nie daje ci wyboru. Istnieją o wiele lepsze narzędzia do śledzenia elementów pracy, raportowania i zarządzania projektami.
Ben Collins,
102
Kluczową różnicą między tymi dwoma systemami jest to, że TFS to scentralizowany system kontroli wersji, a Git to rozproszony system kontroli wersji.
Dzięki TFS repozytoria są przechowywane na centralnym serwerze, a programiści sprawdzają kopię roboczą, która jest migawką kodu w określonym momencie. Dzięki Git programiści klonują całe repozytorium na swoich komputerach, w tym całą historię.
Jedną z korzyści posiadania pełnego repozytorium na komputerach programisty jest nadmiarowość na wypadek śmierci serwera. Kolejną zaletą jest to, że możesz przenosić kopię roboczą w obie strony między wersjami bez rozmowy z serwerem, co może być pomocne, jeśli serwer jest wyłączony lub po prostu nieosiągalny.
Dla mnie prawdziwym dobrodziejstwem jest to, że możesz zatwierdzać zestawy zmian w lokalnym repozytorium, nie rozmawiając z serwerem ani nie powodując potencjalnie niestabilnych zmian w zespole (tj. Przerywając kompilację).
Na przykład, jeśli pracuję nad dużą funkcją, kodowanie i testowanie może zająć tydzień. Nie chcę odpisywać niestabilnego kodu w połowie tygodnia i przerywać kompilacji, ale co się stanie, jeśli zbliżam się do końca tygodnia i przypadkowo zepsuję całą kopię roboczą? Jeśli nie zobowiązuję się przez cały czas, narażam się na utratę pracy. To nie jest skuteczna kontrola wersji, a TFS jest na to podatny.
Dzięki DVCS mogę stale zatwierdzać, nie martwiąc się o przerwanie kompilacji, ponieważ dokonuję zmian lokalnie . W TFS i innych scentralizowanych systemach nie ma koncepcji lokalnego odprawy.
Nie zastanawiałem się nawet, o ile lepsze rozgałęzianie i scalanie jest w DVCS, ale można znaleźć mnóstwo wyjaśnień tutaj na SO lub przez Google. Mogę powiedzieć z doświadczenia, że rozgałęzianie i łączenie w TFS nie jest dobre.
Jeśli argumentem przemawiającym za TFS w twojej organizacji jest to, że działa on lepiej w systemie Windows niż Git, sugerowałbym Mercurial, który działa świetnie w systemie Windows - istnieje integracja z Eksploratorem Windows (TortoiseHg) i Visual Studio (VisualHg).
Jeśli zastanawiasz się nad pójściem z Mercurialem, Joel Spolsky ma świetną stronę z samouczkami do szkolenia swojego zespołu: hginit.com
Martin Owen
3
Warto wspomnieć, że git jest w stanie doskonale emulować scentralizowany system i powszechny jest podstawowy serwer git dla wszystkich użytkowników, po prostu nie musisz tego robić w ten sposób.
Tim Abell
7
jeśli pracujesz nad funkcjonalnością, która może popsuć inne rzeczy - czy nie możesz po prostu utworzyć oddziału w TFS? Jasne - oddział znajduje się na centralnym serwerze - ale czy to naprawdę ma znaczenie? Wygląda na to, że możesz skutecznie zrobić to samo w obu przypadkach - wydaje się, że chodzi raczej o to, jakiego IDE używasz i jak dobrze zintegrowany jest z nim system kontroli wersji -
William
13
Jeśli pracujesz nad dużą funkcją, która potencjalnie może zakłócić działanie zespołu, zaleca się użycie gałęzi funkcji, a następnie, gdy będzie gotowa, połączenie się z gałęzią programistyczną.
Mike Cheel,
9
@MikeCheel To jest świetny komentarz. Możesz także utworzyć Półkę swojego kodu i usunąć ją, gdy w końcu zameldujesz się w swojej funkcji (ale pomysł na rozgałęzienie jest lepszym sposobem na to)
RPDeshaies
86
Ludzie muszą odłożyć broń, odsunąć się od półki i pomyśleć przez chwilę. Okazuje się, że istnieją obiektywne, konkretne i niezaprzeczalne zalety DVCS, które spowodują OGROMNĄ różnicę w wydajności zespołu.
Wszystko sprowadza się do Rozgałęzienia i Scalenia.
Przed DVCS naczelną zasadą było: „Módlcie się do Boga, abyście nie musieli się rozgałęziać i łączyć. A jeśli to zrobicie, przynajmniej błagajcie Go, aby był bardzo, bardzo prosty”.
Teraz, dzięki DVCS, rozgałęzianie ( i łączenie ) jest znacznie ulepszone, naczelną zasadą jest: „Zrób to na wyciągnięcie ręki. Daje to mnóstwo korzyści i nie powoduje żadnych problemów”.
I to jest OGROMNY wzrost wydajności dla każdego zespołu.
Problem polega na tym, że ludzie, aby zrozumieć to, co właśnie powiedziałem i być przekonani, że to prawda, muszą najpierw zainwestować w trochę krzywej uczenia się. Nie muszą uczyć się Git ani żadnego innego DVCS ... muszą tylko nauczyć się, jak Git rozgałęzia się i łączy. Czytaj i czytaj ponownie niektóre artykuły i posty na blogu, spowalniając pracę i przeglądając ją, dopóki jej nie zobaczysz. Może to zająć większą część 2 lub 3 pełnych dni.
Ale kiedy to zobaczysz, nawet nie będziesz rozważać wyboru innego niż DVCS. Ponieważ naprawdę są wyraźne, obiektywne, konkretne zalety DVCS, a największe wygrane są w dziedzinie rozgałęziania i łączenia.
Dzięki, Charlie. Wiem o tym i wiesz o tym, ale trudno jest dotrzeć do ludzi, którzy mówią, że „integracja kontroli źródła z Visual Studio jest dla mnie najważniejszą funkcją”
Jacko
58
Wiem. Razem z przyjacielem rozpowszechnialiśmy tę analogię - wyobraź sobie, że potrzebujesz poważnej relacyjnej bazy danych. Oceniasz Sql Server, Oracle i MS Access. Ostatecznie wybierasz Access, ponieważ ma najładniejszy GUI, mimo że nie można go skalować, nie wymusza bardzo dobrze integralności referencyjnej itp. Rozgałęzianie i Scalanie są absolutnym mięsem i ziemniakami systemu kontroli wersji. Każda inna funkcja jest po prostu odrobinę bling na boku. Ale ludzie dokonują wyborów na podstawie blinga.
Charlie Flowers
17
Chociaż zgadzam się z twoimi stwierdzeniami, nie rozumiem, dlaczego rozgałęzianie i łączenie Git jest „lepsze” tylko dlatego, że jest to system „rozproszony”. Nie jestem pewien, czy bycie DVCS ma coś wspólnego z jego zdolnością do łączenia. Chciałbym wyjaśnić, dlaczego łączenie jest łatwiejsze w systemie rozproszonym. Z mojego doświadczenia, które jest przede wszystkim Git i Svn, łączenie się w SVN jest straszne nie dlatego, że jest scentralizowanym VCS, ale dlatego, że nie śledzi poprawnie poprawek w różnych gałęziach, jak robi to GIT.
CodingWithSpike
8
@ rally25rs - zgadzam się z większością tego. Nie ma powodu, dla którego VCS nie może być dobry w łączeniu. Po prostu nie ma jeszcze (o których wiem). Ale część, z którą się nie zgadzam, to „wyłącznie przez pisanie lepszych procedur scalania, które lepiej rozwiązują konflikty”. Tajny sos nie jest w bardziej inteligentnych procedurach scalania, ale w zasadniczo innym podejściu do tego, jakie informacje przechowujesz w repozytorium i jak je organizujesz. Głównie czyniąc Zasad fundament państwa wewnętrznego. Zatwierdzenia to nie tylko fajne przykręcenie ... to podstawa możliwości.
Charlie Flowers
10
@ rally25rs całkowicie się zgadza, że re: commits jest atomową jednostką pracy. Większość scentralizowanych systemów nie tylko nie porządkuje danych w ten sposób, ale także zniechęca do pracy, którą programiści muszą wykonywać od samego początku, aby naprawdę dobrze działać w trybie rozgałęziania i łączenia. Systemy rozproszone zachęcają do tego, co nazywam „apolitycznymi” zobowiązaniami (samodzielne, małe zobowiązania do odpowiedniej pracy z dobrymi opisami), a systemy scentralizowane zachęcają do tego, co nazywam „bombami różnicowymi”, w których dziurawicie się w jaskini, dopóki nie będziecie gotowi, a następnie upuszczacie dni (lub tygodnie) pracy nad systemem. Zgadnij, który rodzaj najlepiej się łączy?
Ben Collins,
45
Oryginał : @Rob, TFS ma coś o nazwie „ Półki ”, które rozwiązują Twoje obawy związane z zaangażowaniem trwających prac bez wpływu na oficjalną kompilację. Zdaję sobie sprawę, że widzisz centralną kontrolę wersji jako przeszkodę, ale w przypadku TFS sprawdzanie kodu na półce może być postrzegane jako siła b / c, a następnie serwer centralny ma kopię Twojego działania w toku w rzadkim przypadku komputer lokalny ulega awarii lub został zgubiony / skradziony lub musisz szybko zmienić bieg. Chodzi mi o to, że TFS należy odpowiednio pochwalić w tej dziedzinie. Ponadto rozgałęzianie i scalanie w TFS2010 zostało ulepszone w porównaniu z poprzednimi wersjami i nie jest jasne, do której wersji się odnosisz, gdy mówisz „... z doświadczenia, że rozgałęzianie i scalanie w TFS nie jest dobre”. Oświadczenie: Jestem umiarkowanym użytkownikiem TFS2010.
Edytuj Dec-5-2011 : Dla OP jedną rzeczą, która niepokoi mnie w TFS, jest to, że nalega na ustawienie wszystkich plików lokalnych na „tylko do odczytu”, gdy nie pracujesz nad nimi. Jeśli chcesz dokonać zmiany, musisz „wyewidencjonować” plik, który po prostu usuwa atrybut „tylko do odczytu” z pliku, aby TFS wiedział o nim. To niewygodny przepływ pracy. Wolę, aby działał tak, że automatycznie wykrywa, czy dokonałem zmiany, i wcale nie martwi się atrybutami pliku. W ten sposób mogę zmodyfikować plik w Visual Studio, Notatniku lub dowolnym innym narzędziu. Pod tym względem system kontroli wersji powinien być jak najbardziej przejrzysty. Istnieje rozszerzenie Eksploratora Windows ( TFS PowerTools), który pozwala pracować z plikami w Eksploratorze Windows, ale nie upraszcza to znacznie przepływu pracy.
To odpowiada na pytanie, nie powinien to być komentarz, nawet jeśli masz przedstawiciela.
SingleNegationElimination
8
FYI - TFS „11” nie wymaga już bitu tylko do odczytu, jeśli używasz lokalnych obszarów roboczych, które są teraz domyślne. Inteligentnie odkrywa, które pliki są zmieniane z dowolnej aplikacji. Brian Harry ma więcej informacji o ulepszeniach tutaj: blogs.msdn.com/b/bharry/archive/2011/08/02/…
Ed Blankenship
2
@EdBlankenship, dziękuję bardzo za ten link do bloga. To doskonała wiadomość, aby przekonać się, że bzdury bitowe tylko do odczytu są adresowane, aby znacznie ułatwić korzystanie z kolejnej wersji TFS.
Lee Grissom
7
W przeciwieństwie do zobowiązań w branży, takiej jak w przypadku Git, regały nie są łatwe do zrozumienia i zarządzania. Nie wiesz przy każdym zatwierdzeniu, że półka została wykonana i często masz problemy ze scaleniem (jeśli od tego czasu dokonałeś modyfikacji, są one często gubione). Oddział Git jest znacznie potężniejszy i bardziej zrozumiały niż regały. Regały są przeznaczone dla deweloperów, którzy nigdy nie doświadczyli czegoś innego ...
Philippe,
2
Ten przepływ pracy „wyewidencjonowywania” pliku przypomina Visual SourceSafe, ponieważ był to powszechny sposób pracy; pliki zostały pobrane z SourceSafe i przechowywane lokalnie jako pliki tylko do odczytu. Wyewidencjonowanie pliku lub wiązki plików można oznaczyć jako wyłączne, co oznacza, że inni mogą zobaczyć zestaw plików, nad którym pracuje inny programista, aby zapobiec konieczności scalania, gdy rozgałęzianie było wyłączone (prawdopodobnie z powodu prawa świnia w VSS).
), co jest poprawne, TFS to nie tylko VCS. Jedną z głównych funkcji TFS jest wbudowana funkcja śledzenia błędów. Zestawy zmian są powiązane z problemami i mogą być śledzone. Obsługiwane są różne zasady dotyczące meldowań, a także integracja z domeną Windows, którą mają ludzie korzystający z TFS. Ściśle zintegrowane GUI z Visual Studio to kolejny punkt sprzedaży, który przemawia do mniej niż przeciętnego programisty myszy i kliknięć oraz jego menedżera.
Dlatego porównanie Git do TFS nie jest właściwym pytaniem. Prawidłowe, choć niepraktyczne, pytanie dotyczy porównania Git z funkcjami TFS opartymi tylko na VCS. W tym momencie Git wydmuchuje TFS z wody. Jednak każdy poważny zespół potrzebuje innych narzędzi i tutaj TFS zapewnia miejsce docelowe.
Możesz uzyskać te same narzędzia, które zapewnia TFS w dowolnej zwinnej aplikacji narzędziowej. Rajd, nazwij to.
PositiveGuy
2
Chociaż zgadzam się z faktem, że TFS ma szerszy cel, chciałbym przeformułować go tak, aby „PRÓBOWAŁO zapewnić miejsce docelowe typu jeden przystanek”, ale nie jest wystarczająco dobry (przynajmniej nie najlepsza opcja) w żadnym z zadań, które próbuje rozwiązać; to jest jak tępy szwajcarski nóż.
slashCoder
@PositiveGuy nie można go uzyskać bez pracy i konfiguracji. TFS daje Ci wszystko jednym kliknięciem. W tym przypadku cały ekosystem jest teraz dostępny jako usługa w chmurze, bez konieczności konfiguracji zerowej. Jeśli mogę uzyskać kontrolę wersji, wsparcie scrum, automatyczne kompilacje, laboratorium testowe i zarządzanie planem testów, wszystko zintegrowane ze sobą ORAZ korporacyjny LDAP (kłamać AzureAD), za 10 USD / mc, dlaczego mam o tym myśleć próbujesz samodzielnie wkleić kawałki?
Craig Brunetti
1
@slashCoder, jak można oczekiwać, że każdy pełny pakiet będzie najlepszy w każdym kawałku? Czy koszt jego braku najlepszej jakości naprawdę przewyższa koszt samodzielnego zarządzania integracją komponentów? ... może w niektórych miejscach to widzę. Ale prowadzenie takich rzeczy jest czystym kosztem. Co się stanie, jeśli Twój korporacyjny GIT działa dobrze, ale instancja JIRA przestaje działać, a aktualizacja Jenkins nie działa? Dobrze? To jak żonglowanie piłami łańcuchowymi. W ogniu. Częściowo zasłonięte oczy. :) :)
Craig Brunetti
17
Jeśli twój zespół korzysta z TFS i chcesz korzystać z Git, możesz rozważyć mostek „git to tfs”. Zasadniczo pracujesz na co dzień, używając Git na swoim komputerze, a następnie, gdy chcesz wprowadzić zmiany, wypychasz je na serwer TFS.
Tam jest kilka (na github). Użyłem jednego na ostatnim miejscu (wraz z innym programistą) z pewnym sukcesem. Widzieć:
@EdBlankenship, możesz przekonwertować swój komentarz na odpowiedź. Wydaje się być doskonałym rozwiązaniem dla PO. Zagłosuję na to. :)
Lee Grissom,
1
Z wyjątkiem jeśli korzystasz z innej platformy niż Windows, powinieneś preferować git-tfs! git-tf nie jest tak dobry jak git-tfs ... A filozofia jest zorientowana na TFS, podczas gdy git-tfs jest bardziej zorientowany na git (i tego właśnie chcemy!)
Philippe
15
Po pewnym dochodzeniu między za i przeciw, firma, z którą byłem zaangażowany, postanowiła wybrać TFS. Nie dlatego, że GIT nie jest dobrym systemem kontroli wersji, ale co najważniejsze dla w pełni zintegrowanego rozwiązania ALM dostarczanego przez TFS. Jeśli ważna była tylko funkcja kontroli wersji, prawdopodobnie to był wybór GIT. Stromej krzywej uczenia się GIT dla zwykłych programistów nie można jednak nie docenić.
Być może, ale każda część TFS jest zła i trudna w administrowaniu (w rzeczywistości potrzebujesz prawdziwego administratora TFS). Spójrz Git> TFS (VCS), Jenkins> TFS (CI), nunit lub xunit> mstest, IceScrum lub ...> TFS (Zarządzanie projektami). TFS to dobry pomysł na początek, dopóki go nie użyjesz !!!
Philippe,
1
dlaczego potrzebujesz TFS, po prostu uzyskaj dobrą zwinną aplikację. A następnie użyj Git lub subversion i jesteś na dobrej drodze. TFS po prostu przeszkadza, wpędzając cię w problemy.
PositiveGuy
Aktualizacja: TFS 2013 (serwer) [i VS12-13) obsługuje teraz git do kontroli wersji. Możesz więc uzyskać to, co najlepsze z obu światów
DarcyThomas
2
Jasne, miło jest mieć w pełni zintegrowany ALM. Ale nie kosztem elastyczności. IMO. ALM powinien być skonstruowany przy użyciu możliwie największej technologii „najlepszej rasy” ... a przynajmniej elastyczności w integracji najlepszych ras, ponieważ z czasem mogą się one zmieniać. Wybór TFS to po prostu stawka w gruncie rzeczy, mówiąc: „Microsoft wygra we wszystkich aspektach mojego ALM”, co jest głupie. Użyłem na przykład Git w / Jira, co pozwoliło mi zaktualizować / zamknąć problemy na podstawie mojego komunikatu zatwierdzenia. Z mojego doświadczenia (również z TFS) jest to znacznie lepszy przepływ pracy.
Scott Silvi
1
Pasek boczny - nawet przy integracji TFS / Git, w zasadzie mówisz „pozwala wyposażyć VCS w Git, zachowując nasze śledzenie problemów” - zasadniczo nie różni się to od używania Git z innym oprogramowaniem do śledzenia problemów. Nie jestem więc pewien, czy argument ALM jest już poprawny, biorąc pod uwagę, że Microsofty próbują elastyczności (co pochwalam).
Scott Silvi
14
Cała rozproszona sprawa Git jest naprawdę świetna. daje kilka funkcji, których nie ma w zestawach półek (w bieżącym produkcie), takie jak lokalne opcje wycofywania i zatwierdzania (takie jak lokalna historia Eclipse ). Możesz to złagodzić za pomocą gałęzi programistów, ale bądźmy szczerzy, wielu programistów nie lubi rozgałęziania ani łączenia. Poproszono mnie o kilkakrotne włączanie funkcji TFS „wyłącznego kasowania” w starym stylu w TFS (i za każdym razem odmawiałem).
Myślę, że wiele dużych firm bardzo się boi, aby pozwolić deweloperowi po prostu przenieść całą historię do lokalnego miejsca pracy i zabrać ją ze sobą (na przykład do nowego pracodawcy) ... Kradzież migawki jest zła, ale zabiera całą historię jest jeszcze bardziej kłopotliwy. (Nie żebyś nie mógł uzyskać pełnej historii od TFS, której chciałeś) ...
Wspomniano, że jest to świetny sposób na tworzenie kopii zapasowych, który jest świetny dla open source, w którym pierwotny opiekun może przestać dbać i usuwa swoją wersję, ale w przypadku planu korporacyjnego to znowu nie wystarcza dla wielu przedsiębiorstw, ponieważ nie ma wyraźnego przypisania odpowiedzialności zachować kopie zapasowe. I trudno byłoby ustalić, której wersji użyć, jeśli główny „projekt” jakoś zniknie. Który miałby tendencję do wyznaczania jednego repozytorium jako wiodącego / centralnego.
W Git najbardziej podoba mi się opcja Push / Pull, w której możesz łatwo wnieść kod do projektu bez konieczności posiadania uprawnień do zatwierdzania. Myślę, że możesz użyć bardzo ograniczonej liczby użytkowników i półek w TFS, aby to naśladować, ale nie jest tak potężny jak opcja Git. Rozgałęzienie między projektami zespołowymi może również działać, ale z administracyjnego punktu widzenia nie jest tak naprawdę wykonalne dla wielu organizacji, ponieważ dodawanie projektów zespołowych powoduje znaczne obciążenie administracyjne.
Chciałbym również dodać do rzeczy wymienionych w obszarze kontroli bez źródła. Funkcje takie jak śledzenie elementów pracy, raportowanie i automatyzacja kompilacji (w tym zarządzanie laboratorium) w dużym stopniu korzystają z centralnego wiodącego repozytorium. Stają się one znacznie trudniejsze, gdy używasz czysto rozproszonego modelu, chyba że zrobisz jeden z węzłów prowadzących (i w ten sposób wrócisz do mniej rozproszonego modelu).
Z TFS Basic w połączeniu z TFS 11, może nie być dalekim oczekiwaniem rozproszonego TFS, który pozwala zsynchronizować lokalny TFS Basic z centralnym TFS w erze TFS 12+. Włożę mój głos na tym puchu w UserVoice !
Ta cała odpowiedź szybko staje się przestarzała. Microsoft dodał obsługę Git do usługi Team Foundation Service i doda obsługę Git do następnej głównej wersji Team Foundation Server.
jessehouwing
1
@Philippe: Próbowałem obu. Kilka różnic: 1) git-tf działa na różnych platformach, podczas gdy git-tfs działa tylko w systemie Windows. 2) git-tfs przepisuje opisy zatwierdzeń, kiedy „wypychasz”, aby uwzględnić numer zestawu zmian, podczas gdy git-tf pozostawia nietknięte twoje lokalne skróty zatwierdzeń.
Joey Adams
@JeyeyAdams 1) +1, to jedyny dobry powód, aby wybrać git-tf 2) Możesz to również zrobić z git-tfs za pomocą checkinpolecenia (zamiast rcheckin). Ale wolę rcheckin, ponieważ jest to bardziej gitowy sposób na robienie rzeczy i dlatego wybraliśmy git;)
Philippe
9
Dla mnie główna różnica polega na tym, że wszystkie pliki pomocnicze, które TFS doda do twojego rozwiązania (.vssscc) w celu „wsparcia” TFS - mieliśmy ostatnie problemy z mapowaniem tych plików do niewłaściwej gałęzi, co prowadzi do interesujących debugowania ...
Dobra racja tutaj. Git doda .gitfolder, aby śledzić wszystkie szczegóły repozytorium. TFS zmodyfikuje przynajmniej twoje pliki .sln(a może to .csproj?), Aby umieścić w nim lokalizację zdalnego repozytorium.
CodingWithSpike
5
Zapomniałem, jak bardzo nienawidziłem tego, jak VSS modyfikowałby twoje pliki „dla” ciebie.
Odpowiedzi:
Myślę, że oświadczenie
marnuje wszelkie dalsze dyskusje: gdy będziesz nadal używać Git, obwinią cię, jeśli coś pójdzie nie tak.
Poza tym Git ma dla mnie dwie zalety w stosunku do scentralizowanego VCS, które najbardziej doceniam (jak częściowo opisał Rob Sobers ):
Ale jak powiedziałem: myślę, że stoczysz przegraną bitwę: kiedy wszyscy nienawidzą Gita, nie używaj Gita. Może ci to pomóc dowiedzieć się, dlaczego nienawidzą Gita, zamiast próbować ich przekonać.
Jeśli po prostu tego nie chcą, bo to dla nich nowość i nie chcą nauczyć się czegoś nowego: czy jesteś pewien, że uda ci się z powodzeniem opracować ten zespół?
Czy naprawdę każda osoba nienawidzi Gita, czy ma na nią wpływ niektórzy przywódcy opinii? Znajdź liderów i zapytaj ich, w czym problem. Przekonaj ich, a przekonasz resztę zespołu.
Jeśli nie możesz przekonać liderów: zapomnij o użyciu Git, weź TFS. Ułatwi ci życie.
źródło
Kluczową różnicą między tymi dwoma systemami jest to, że TFS to scentralizowany system kontroli wersji, a Git to rozproszony system kontroli wersji.
Dzięki TFS repozytoria są przechowywane na centralnym serwerze, a programiści sprawdzają kopię roboczą, która jest migawką kodu w określonym momencie. Dzięki Git programiści klonują całe repozytorium na swoich komputerach, w tym całą historię.
Jedną z korzyści posiadania pełnego repozytorium na komputerach programisty jest nadmiarowość na wypadek śmierci serwera. Kolejną zaletą jest to, że możesz przenosić kopię roboczą w obie strony między wersjami bez rozmowy z serwerem, co może być pomocne, jeśli serwer jest wyłączony lub po prostu nieosiągalny.
Dla mnie prawdziwym dobrodziejstwem jest to, że możesz zatwierdzać zestawy zmian w lokalnym repozytorium, nie rozmawiając z serwerem ani nie powodując potencjalnie niestabilnych zmian w zespole (tj. Przerywając kompilację).
Na przykład, jeśli pracuję nad dużą funkcją, kodowanie i testowanie może zająć tydzień. Nie chcę odpisywać niestabilnego kodu w połowie tygodnia i przerywać kompilacji, ale co się stanie, jeśli zbliżam się do końca tygodnia i przypadkowo zepsuję całą kopię roboczą? Jeśli nie zobowiązuję się przez cały czas, narażam się na utratę pracy. To nie jest skuteczna kontrola wersji, a TFS jest na to podatny.
Dzięki DVCS mogę stale zatwierdzać, nie martwiąc się o przerwanie kompilacji, ponieważ dokonuję zmian lokalnie . W TFS i innych scentralizowanych systemach nie ma koncepcji lokalnego odprawy.
Nie zastanawiałem się nawet, o ile lepsze rozgałęzianie i scalanie jest w DVCS, ale można znaleźć mnóstwo wyjaśnień tutaj na SO lub przez Google. Mogę powiedzieć z doświadczenia, że rozgałęzianie i łączenie w TFS nie jest dobre.
Jeśli argumentem przemawiającym za TFS w twojej organizacji jest to, że działa on lepiej w systemie Windows niż Git, sugerowałbym Mercurial, który działa świetnie w systemie Windows - istnieje integracja z Eksploratorem Windows (TortoiseHg) i Visual Studio (VisualHg).
źródło
Ludzie muszą odłożyć broń, odsunąć się od półki i pomyśleć przez chwilę. Okazuje się, że istnieją obiektywne, konkretne i niezaprzeczalne zalety DVCS, które spowodują OGROMNĄ różnicę w wydajności zespołu.
Wszystko sprowadza się do Rozgałęzienia i Scalenia.
Przed DVCS naczelną zasadą było: „Módlcie się do Boga, abyście nie musieli się rozgałęziać i łączyć. A jeśli to zrobicie, przynajmniej błagajcie Go, aby był bardzo, bardzo prosty”.
Teraz, dzięki DVCS, rozgałęzianie ( i łączenie ) jest znacznie ulepszone, naczelną zasadą jest: „Zrób to na wyciągnięcie ręki. Daje to mnóstwo korzyści i nie powoduje żadnych problemów”.
I to jest OGROMNY wzrost wydajności dla każdego zespołu.
Problem polega na tym, że ludzie, aby zrozumieć to, co właśnie powiedziałem i być przekonani, że to prawda, muszą najpierw zainwestować w trochę krzywej uczenia się. Nie muszą uczyć się Git ani żadnego innego DVCS ... muszą tylko nauczyć się, jak Git rozgałęzia się i łączy. Czytaj i czytaj ponownie niektóre artykuły i posty na blogu, spowalniając pracę i przeglądając ją, dopóki jej nie zobaczysz. Może to zająć większą część 2 lub 3 pełnych dni.
Ale kiedy to zobaczysz, nawet nie będziesz rozważać wyboru innego niż DVCS. Ponieważ naprawdę są wyraźne, obiektywne, konkretne zalety DVCS, a największe wygrane są w dziedzinie rozgałęziania i łączenia.
źródło
Oryginał : @Rob, TFS ma coś o nazwie „ Półki ”, które rozwiązują Twoje obawy związane z zaangażowaniem trwających prac bez wpływu na oficjalną kompilację. Zdaję sobie sprawę, że widzisz centralną kontrolę wersji jako przeszkodę, ale w przypadku TFS sprawdzanie kodu na półce może być postrzegane jako siła b / c, a następnie serwer centralny ma kopię Twojego działania w toku w rzadkim przypadku komputer lokalny ulega awarii lub został zgubiony / skradziony lub musisz szybko zmienić bieg. Chodzi mi o to, że TFS należy odpowiednio pochwalić w tej dziedzinie. Ponadto rozgałęzianie i scalanie w TFS2010 zostało ulepszone w porównaniu z poprzednimi wersjami i nie jest jasne, do której wersji się odnosisz, gdy mówisz „... z doświadczenia, że rozgałęzianie i scalanie w TFS nie jest dobre”. Oświadczenie: Jestem umiarkowanym użytkownikiem TFS2010.
Edytuj Dec-5-2011 : Dla OP jedną rzeczą, która niepokoi mnie w TFS, jest to, że nalega na ustawienie wszystkich plików lokalnych na „tylko do odczytu”, gdy nie pracujesz nad nimi. Jeśli chcesz dokonać zmiany, musisz „wyewidencjonować” plik, który po prostu usuwa atrybut „tylko do odczytu” z pliku, aby TFS wiedział o nim. To niewygodny przepływ pracy. Wolę, aby działał tak, że automatycznie wykrywa, czy dokonałem zmiany, i wcale nie martwi się atrybutami pliku. W ten sposób mogę zmodyfikować plik w Visual Studio, Notatniku lub dowolnym innym narzędziu. Pod tym względem system kontroli wersji powinien być jak najbardziej przejrzysty. Istnieje rozszerzenie Eksploratora Windows ( TFS PowerTools), który pozwala pracować z plikami w Eksploratorze Windows, ale nie upraszcza to znacznie przepływu pracy.
źródło
Na dodatek wszystko, co zostało powiedziane (
), co jest poprawne, TFS to nie tylko VCS. Jedną z głównych funkcji TFS jest wbudowana funkcja śledzenia błędów. Zestawy zmian są powiązane z problemami i mogą być śledzone. Obsługiwane są różne zasady dotyczące meldowań, a także integracja z domeną Windows, którą mają ludzie korzystający z TFS. Ściśle zintegrowane GUI z Visual Studio to kolejny punkt sprzedaży, który przemawia do
mniej niż przeciętnego programistymyszy i kliknięć oraz jego menedżera.Dlatego porównanie Git do TFS nie jest właściwym pytaniem. Prawidłowe, choć niepraktyczne, pytanie dotyczy porównania Git z funkcjami TFS opartymi tylko na VCS. W tym momencie Git wydmuchuje TFS z wody. Jednak każdy poważny zespół potrzebuje innych narzędzi i tutaj TFS zapewnia miejsce docelowe.
źródło
Jeśli twój zespół korzysta z TFS i chcesz korzystać z Git, możesz rozważyć mostek „git to tfs”. Zasadniczo pracujesz na co dzień, używając Git na swoim komputerze, a następnie, gdy chcesz wprowadzić zmiany, wypychasz je na serwer TFS.
Tam jest kilka (na github). Użyłem jednego na ostatnim miejscu (wraz z innym programistą) z pewnym sukcesem. Widzieć:
https://github.com/spraints/git-tfs
https://github.com/git-tfs/git-tfs
źródło
Po pewnym dochodzeniu między za i przeciw, firma, z którą byłem zaangażowany, postanowiła wybrać TFS. Nie dlatego, że GIT nie jest dobrym systemem kontroli wersji, ale co najważniejsze dla w pełni zintegrowanego rozwiązania ALM dostarczanego przez TFS. Jeśli ważna była tylko funkcja kontroli wersji, prawdopodobnie to był wybór GIT. Stromej krzywej uczenia się GIT dla zwykłych programistów nie można jednak nie docenić.
Zobacz szczegółowe wyjaśnienie w moim blogu TFS jako prawdziwa platforma obejmująca wiele technologii .
źródło
Cała rozproszona sprawa Git jest naprawdę świetna. daje kilka funkcji, których nie ma w zestawach półek (w bieżącym produkcie), takie jak lokalne opcje wycofywania i zatwierdzania (takie jak lokalna historia Eclipse ). Możesz to złagodzić za pomocą gałęzi programistów, ale bądźmy szczerzy, wielu programistów nie lubi rozgałęziania ani łączenia. Poproszono mnie o kilkakrotne włączanie funkcji TFS „wyłącznego kasowania” w starym stylu w TFS (i za każdym razem odmawiałem).
Myślę, że wiele dużych firm bardzo się boi, aby pozwolić deweloperowi po prostu przenieść całą historię do lokalnego miejsca pracy i zabrać ją ze sobą (na przykład do nowego pracodawcy) ... Kradzież migawki jest zła, ale zabiera całą historię jest jeszcze bardziej kłopotliwy. (Nie żebyś nie mógł uzyskać pełnej historii od TFS, której chciałeś) ...
Wspomniano, że jest to świetny sposób na tworzenie kopii zapasowych, który jest świetny dla open source, w którym pierwotny opiekun może przestać dbać i usuwa swoją wersję, ale w przypadku planu korporacyjnego to znowu nie wystarcza dla wielu przedsiębiorstw, ponieważ nie ma wyraźnego przypisania odpowiedzialności zachować kopie zapasowe. I trudno byłoby ustalić, której wersji użyć, jeśli główny „projekt” jakoś zniknie. Który miałby tendencję do wyznaczania jednego repozytorium jako wiodącego / centralnego.
W Git najbardziej podoba mi się opcja Push / Pull, w której możesz łatwo wnieść kod do projektu bez konieczności posiadania uprawnień do zatwierdzania. Myślę, że możesz użyć bardzo ograniczonej liczby użytkowników i półek w TFS, aby to naśladować, ale nie jest tak potężny jak opcja Git. Rozgałęzienie między projektami zespołowymi może również działać, ale z administracyjnego punktu widzenia nie jest tak naprawdę wykonalne dla wielu organizacji, ponieważ dodawanie projektów zespołowych powoduje znaczne obciążenie administracyjne.
Chciałbym również dodać do rzeczy wymienionych w obszarze kontroli bez źródła. Funkcje takie jak śledzenie elementów pracy, raportowanie i automatyzacja kompilacji (w tym zarządzanie laboratorium) w dużym stopniu korzystają z centralnego wiodącego repozytorium. Stają się one znacznie trudniejsze, gdy używasz czysto rozproszonego modelu, chyba że zrobisz jeden z węzłów prowadzących (i w ten sposób wrócisz do mniej rozproszonego modelu).
Z TFS Basic w połączeniu z TFS 11, może nie być dalekim oczekiwaniem rozproszonego TFS, który pozwala zsynchronizować lokalny TFS Basic z centralnym TFS w erze TFS 12+. Włożę mój głos na tym puchu w UserVoice !
źródło
checkinpolecenia (zamiast rcheckin). Ale wolę rcheckin, ponieważ jest to bardziej gitowy sposób na robienie rzeczy i dlatego wybraliśmy git;)Dla mnie główna różnica polega na tym, że wszystkie pliki pomocnicze, które TFS doda do twojego rozwiązania (.vssscc) w celu „wsparcia” TFS - mieliśmy ostatnie problemy z mapowaniem tych plików do niewłaściwej gałęzi, co prowadzi do interesujących debugowania ...
źródło
.gitfolder, aby śledzić wszystkie szczegóły repozytorium. TFS zmodyfikuje przynajmniej twoje pliki.sln(a może to.csproj?), Aby umieścić w nim lokalizację zdalnego repozytorium.