Git vs Team Foundation Server [zamknięte]

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?

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.

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).

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.

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.

Na dodatek wszystko, co zostało powiedziane (

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

), 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.

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

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 .

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 !

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 ...