Dlaczego Git jest lepszy od Subversion?

Z Gitem możesz zrobić praktycznie wszystko offline, ponieważ każdy ma swoje własne repozytorium.

Tworzenie gałęzi i łączenie między gałęziami jest naprawdę łatwe.

Nawet jeśli nie masz uprawnień do zatwierdzania projektu, nadal możesz mieć własne repozytorium online i publikować "push requests" dla swoich poprawek. Każdy, kto lubi wasze patche, może włączyć je do swojego projektu, w tym oficjalni opiekunowie.

Trywialne jest rozwidlenie projektu, zmodyfikowanie go, a mimo to Kontynuuj scalanie w poprawkach błędów z gałęzi głównej.

Git działa dla programistów jądra Linuksa. Oznacza to, że jest naprawdę szybki (musi być) i skaluje się do tysięcy współpracowników. Git również zużywa mniej miejsca (do 30 razy mniej miejsca dla repozytorium Mozilli).

Git jest bardzo elastyczny, bardzo TIMTOWTDI(jest na to więcej niż jeden sposób). Możesz użyć dowolnego przepływu pracy, a Git go wesprze.

Wreszcie jest GitHub , świetna strona do hostingu repozytoria Gita.

Wady Git:

• jest o wiele trudniej się tego nauczyć, ponieważ Git ma więcej pojęć i więcej poleceń.
• wersje nie mają numerów wersji, jak w subversion
Wiele poleceń Gita jest tajemniczych, a komunikaty o błędach są bardzo nieprzyjazne dla użytkownika.]} [[19]}brakuje dobrego GUI (takiego jak wielki TortoiseSVN )

Inne odpowiedzi wykonały dobrą robotę wyjaśniając podstawowe funkcje Gita (które są świetne). Ale jest też tak wiele małych sposobów na to, że Git zachowuje się lepiej i pomaga utrzymać moje życie bardziej przy zdrowych zmysłach. Oto kilka drobiazgów:

1. Git posiada polecenie 'clean'. SVN desperacko potrzebuje tego polecenia, biorąc pod uwagę, jak często zrzuca dodatkowe pliki na twój dysk.
2. Git posiada polecenie 'bisect'. To miłe.
3. SVN tworzy .katalogi svn w każdym folder (Git tworzy tylko Jeden .katalog git). Każdy skrypt, który piszesz i każdy grep, który wykonujesz, będzie musiał zostać napisany, aby je zignorować .katalogi svn. Potrzebujesz również całego polecenia ("svn export"), aby uzyskać zdrową kopię swoich plików.
4. W SVN każdy plik i folder może pochodzić z innej wersji lub gałęzi. Na początku miło jest mieć tę wolność. Ale to naprawdę oznacza, że istnieje milion różnych sposobów na to, aby Twoja lokalna kasa była całkowicie wkręcona w górę. (na przykład, jeśli "svn switch" zawiedzie w połowie lub jeśli wprowadzisz błędne polecenie). A najgorsze jest to, że jeśli kiedykolwiek znajdziesz się w sytuacji, w której niektóre Twoje pliki pochodzą z jednego miejsca, a niektóre z nich z innego, "status svn" powie Ci, że wszystko jest normalne. Musisz zrobić "svn info" na każdym pliku / katalogu, aby odkryć, jak dziwne są rzeczy. Jeśli "git status" mówi ci, że rzeczy są normalne, możesz zaufać, że rzeczy naprawdę są normalne.
5. musisz powiedz SVN za każdym razem, gdy coś przeniesiesz lub usuniesz. Git po prostu to rozgryzie.
6. semantyka ignorowania jest łatwiejsza w Git. Jeśli zignorujesz wzorzec (taki jak *.pyc), będzie ignorowany dla wszystkich podkatalogów. (Ale jeśli naprawdę chcesz coś zignorować tylko dla jednego katalogu, możesz). W przypadku SVN wydaje się, że nie ma łatwego sposobu na zignorowanie wzorca we wszystkich podkatalogach.
7. kolejny element zawierający ignorowane pliki. Git umożliwia "prywatne" ustawienia ignorowania (używając akta .git / info / exclude), co nie wpłynie na nikogo innego.

"Dlaczego Git jest lepszy niż X " przedstawia różne plusy i minusy Git vs inne SCM.

Krótko:

• Git śledzi zawartość zamiast plików
• gałęzie są lekkie a scalanie jest łatwe , i mam na myśli naprawdę łatwe .
• jest rozproszone, w zasadzie każde repozytorium jest gałęzią. Moim zdaniem o wiele łatwiej jest rozwijać się równolegle i wspólnie niż z Subversion. To również sprawia, że offline rozwój możliwy.
• It nie narzuca żadnego przepływu pracy , Jak widać na powyższej linkowanej stronie, Istnieje wiele przepływów pracy możliwych Z Gitem. Przepływ pracy w stylu Subversion można łatwo naśladować.
• repozytoria Git są znacznie mniejsze pod względem rozmiaru pliku niż repozytoria Subversion. Jest tylko jeden".git "katalog, w przeciwieństwie do dziesiątek".svn " repozytoria (Uwaga Subversion 1.7 i wyższe używa teraz jednego katalogu Jak Git.)
• obszar staging jest niesamowity, pozwala zobaczyć zmiany, które zatwierdzisz, zatwierdzisz częściowe zmiany i zrobisz różne inne rzeczy.
• Przechowywanie jest nieocenione, gdy robisz "chaotyczny" rozwój, lub po prostu chcesz naprawić błąd, gdy nadal pracujesz nad czymś innym(na innej gałęzi).
• Możesz przepisać historię , co świetnie nadaje się do przygotowywania zestawów patchów i naprawiania błędów (zanim opublikujesz commits)
• ... i więcej.

Są pewne wady:

• nie ma jeszcze wielu dobrych GUI do tego. Jest nowy i Subversion istnieje już znacznie dłużej, więc jest to naturalne, ponieważ w rozwoju jest kilka interfejsów. Niektóre dobre to TortoiseGit i GitHub dla Mac .
• częściowe checkouts/klony repozytoriów nie są w tej chwili możliwe(czytałem, że jest w fazie rozwoju). Jest jednak wsparcie podmodułu. Git 1.7 + obsługuje nieliczne checkouts .
• może być trudniej się tego nauczyć, chociaż nie uznałem tego za przypadek (około rok temu). Git niedawno ulepszył swój interfejs i jest dość przyjazny dla użytkownika.

W najbardziej uproszczonym użyciu, Subversion i Git są prawie takie same. Nie ma dużej różnicy między:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

I

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Gdzie Git naprawdę świeci to rozgałęzianie się i praca z innymi ludźmi.

Google Tech Talk: Linus Torvalds na git

Http://www.youtube.com/watch?v=4XpnKHJAok8

Strona porównawcza Git Wiki

Http://git.or.cz/gitwiki/GitSvnComparsion

Cóż, jest rozprowadzany. Benchmarki wskazują, że jest on znacznie szybszy (biorąc pod uwagę jego rozproszony charakter, operacje takie jak diff i logi są lokalne, więc oczywiście w tym przypadku jest niesamowicie szybszy), a działające foldery są mniejsze (co nadal mnie rozwala).

Kiedy pracujesz nad subversion lub innym systemem kontroli wersji klienta/serwera, zasadniczo tworzysz kopie robocze na swoim komputerze przez sprawdzanie rewizji. Stanowi to migawkę w czasie jak wygląda repozytorium. Aktualizujesz kopię roboczą za pomocą aktualizacji, a repozytorium za pomocą commitów.

Z rozproszoną kontrolą wersji, nie masz migawki, ale raczej całą bazę kodu. Chcesz zrobić diff z 3 miesięczną wersją? Nie ma problemu, 3-miesięczna wersja nadal jest na twoim komputerze. Oznacza to nie tylko, że wszystko przebiega znacznie szybciej, ale jeśli zostaniesz odłączony od centralnego serwera, nadal możesz wykonywać wiele operacji, do których jesteś przyzwyczajony. W innych słowa, Masz nie tylko migawkę danej wersji, ale cały kod.

Można by pomyśleć, że Git zajmie trochę miejsca na dysku twardym, ale z kilku benchmarków, które widziałem, faktycznie zajmuje mniej. Nie pytaj mnie jak. To znaczy, został zbudowany przez Linusa, on wie co nieco o systemach plików.

Główne punkty, które lubię o DVC są takie:

Możesz popełnić zepsute rzeczy. To nie ma znaczenia, bo inne narody nie zobaczą ich, dopóki nie opublikujesz. Czas publikacji różni się od czasu zatwierdzenia.
1. z tego powodu możesz się częściej angażować.
2. możesz połączyć pełną funkcjonalność. Ta funkcjonalność będzie miała własną gałąź. Wszystkie commity tej gałęzi będą powiązane z tą funkcjonalnością. Można to zrobić z CVCS jednak z DVCS jego default.
3. Możesz przeszukiwać swoją historię (znaleźć po zmianie funkcji)
4. możesz cofnąć pull jeśli ktoś zepsuje główne repozytorium, nie musisz naprawiać błędów. Po prostu wyczyść połączenie.
5. Gdy potrzebujesz kontroli źródła w dowolnym katalogu, wykonaj : git init . i możesz zatwierdzać, cofać zmiany itp...
Jest szybki (nawet w Windows)

Głównym powodem stosunkowo dużego projektu jest ulepszona komunikacja stworzona przez punkt 3. Inni są mili bonusy.

The funny thing is: Hostuję projekty w Reposach Subversion, ale uzyskuję do nich dostęp poprzez polecenie git Clone.

Proszę przeczytać rozwijać z Git na Google Code Project

Chociaż Google Code natywnie mówi Subversion, możesz łatwo użyć Git podczas rozwoju. Szukam "git svn " sugeruje, że praktyka ta jest szeroko rozpowszechnione, a także zachęcamy do eksperymentować z nim.

Używanie Gita na repozytorium Svn daje mi zalety:

1. mogę pracować dystrybuowane na kilku maszyny, Maszyny i urządzenia i do nich
2. mam centralny backup/public repozytorium svn dla innych do sprawdzenia
3. i mogą swobodnie używać Gita dla swoich własnych

Wszystkie odpowiedzi są zgodne z oczekiwaniami, zorientowane na programistów, ale co się stanie, jeśli Twoja firma będzie korzystać z kontroli wersji poza kodem źródłowym? Istnieje wiele dokumentów, które nie są kodem źródłowym, które korzystają z kontroli wersji i powinny żyć blisko kodu, a nie w innym CMS. Większość programistów nie pracuje w izolacji - pracujemy dla firm jako część zespołu.

Mając to na uwadze, porównaj łatwość użycia, zarówno w narzędziach klienckich, jak i w szkoleniach, pomiędzy Subversion i git. I nie widzę scenariusza, w którym dowolny rozproszony system kontroli wersji będzie łatwiejszy w użyciu lub wyjaśnieniu nie-programiście. Chciałbym się mylić, ponieważ wtedy byłbym w stanie ocenić Gita i mieć nadzieję, że zostanie on zaakceptowany przez ludzi, którzy potrzebują kontroli wersji, którzy nie są programistami.

Nawet wtedy, gdy kierownictwo zapyta, Dlaczego powinniśmy przejść z scentralizowanego do rozproszonego systemu kontroli rewizji, trudno będzie mi udzielić uczciwej odpowiedzi, ponieważ nie potrzebuję tego.

Disclaimer: zainteresowałem się Subversion na początku (około v0.29), więc oczywiście jestem stronniczy, ale firmy, dla których pracowałem od tego czasu, korzystają z mojego entuzjazmu, ponieważ zachęcałem i wspierałem jego użycie. Podejrzewam, że tak to się dzieje z większością firm programistycznych. Przy tak wielu programistach skaczących na Git bandwagon, zastanawiam się, ile firm przegapi korzyści płynące z używania kontroli wersji poza kodem źródłowym? Nawet jeśli mając oddzielne systemy dla różnych zespołów, tracisz niektóre korzyści, takie jak (zunifikowana) integracja śledzenia problemów, jednocześnie zwiększając wymagania konserwacyjne, sprzętowe i szkoleniowe.

Subversion jest nadal dużo bardziej używanym systemem kontroli wersji, co oznacza, że ma lepsze wsparcie dla narzędzi. Znajdziesz Dojrzałe wtyczki SVN dla prawie każdego IDE, A dostępne są dobre rozszerzenia Eksploratora (takie jak TurtoiseSVN). Poza tym muszę się zgodzić z Michael : Git nie jest lepszy ani gorszy od Subversion, to co innego.

Jedną z rzeczy w SubVersion, która mnie irytuje, jest to, że umieszcza swój własny folder w każdym katalogu projektu, podczas gdy git umieszcza tylko jeden w katalogu głównym. To nie jest to wielka sprawa, ale takie małe rzeczy się sumują.

Oczywiście, SubVersion ma żółwia, który jest [zazwyczaj] bardzo ładny.

David Richards WANdisco Blog o Subversion / GIT

Pojawienie się Gita przyniosło ze sobą rasę fundamentalistów DVCS - ' Gitteronów – - którzy myślą, że wszystko inne niż GIT jest do dupy. Gitteronowie zdają się myśleć, że inżynieria oprogramowania dzieje się na ich własnej wyspie i często zapominają, że większość organizacji nie zatrudnia wyłącznie starszych inżynierów oprogramowania. To jest ok, ale nie tak myśli reszta rynku, a ja chętnie to udowodnię: GIT, w końcu look miał mniej niż trzy procent rynku, podczas gdy Subversion ma w regionie pięciu milionów użytkowników i około połowy całego rynku.

Problem, który widzieliśmy, polegał na tym, że Gitteronowie strzelali (tanimi) strzałami w Subversion. Tweety typu " Subversion jest taki [powolny/gówniany/restrykcyjny / nie pachnie dobrze / patrzy na mnie w zabawny sposób] i teraz mam GIT i [wszystko działa w moim życiu/moja żona zaszła w ciążę/mam dziewczynę po 30 latach prób/wygrałem sześć razy biegając na blackjack table]. Rozumiesz.

Git również ułatwia rozgałęzianie i scalanie. Subversion 1.5 właśnie dodał śledzenie scalania, ale Git jest jeszcze lepszy. Z Gitem rozgałęzianie jest bardzo szybkie i tanie. To sprawia, że tworzenie gałęzi dla każdej nowej funkcji jest bardziej możliwe. Repozytoria Oh I Git są bardzo wydajne z pamięcią masową w porównaniu z Subversion.

Chodzi o łatwość użycia / kroki wymagane, aby coś zrobić.

Jeśli rozwijam pojedynczy projekt na moim PC/laptopie, git jest lepszy, ponieważ jest znacznie łatwiejszy w konfiguracji i użyciu. Nie potrzebujesz serwera i nie musisz wpisywać adresu URL repozytorium podczas łączenia.

Gdyby to były tylko 2 osoby, powiedziałbym, że git jest również łatwiejszy, ponieważ można po prostu pchać i ciągnąć od siebie.

Jak już to przekroczysz, to pójdę na subversion, bo w tym momencie musisz skonfigurować "dedykowany" serwer lub lokalizację.

Możesz to zrobić tak samo dobrze z Gitem jak z SVN, ale korzyści z Gita przewyższają konieczność wykonania dodatkowych kroków w celu synchronizacji z centralnym serwerem. W SVN po prostu się zobowiązujesz. W git musisz git commit, a następnie git push. Dodatkowy krok staje się denerwujący, po prostu dlatego, że robisz to tak bardzo.

SVN ma również zalety lepszych narzędzi GUI, jednak ekosystem git wydaje się szybko nadrabiać zaległości, więc nie martwiłbym się tym na dłuższą metę.

Easy git ma ładną stronę porównującą rzeczywiste użycie Git i SVN, która da ci wyobrażenie o tym, co Git może zrobić (lub zrobić łatwiej) w porównaniu do SVN. (Technicznie rzecz biorąc, jest to oparte na Easy Git, który jest lekkim opakowaniem na Git.)

Git i DVCS w ogóle są świetne dla programistów wykonujących wiele kodowania niezależnie od siebie, ponieważ każdy ma swoją własną gałąź. Jeśli jednak potrzebujesz zmiany od kogoś innego, ona musi zobowiązać się do lokalnego repo, a następnie musi wcisnąć ten zestaw zmian do ciebie lub musisz wyciągnąć go od niej.

Moje własne rozumowanie również sprawia, że myślę, że DVCS utrudnia QA i zarządzanie wydaniami, jeśli robisz rzeczy takie jak scentralizowane wydania. Ktoś musi być za to odpowiedzialny. push / pull z repozytorium wszystkich innych, rozwiązując wszelkie konflikty, które zostały rozwiązane w początkowym czasie commit przed, następnie wykonując kompilację, a następnie wszystkich innych programistów ponownie zsynchronizować swoje repos.

Wszystko to można rozwiązać za pomocą procesów ludzkich, oczywiście; DVC właśnie zepsuło coś, co zostało naprawione przez scentralizowaną kontrolę wersji w celu zapewnienia nowych udogodnień.

Lubię Git, ponieważ pomaga w komunikacji między programistą a programistą w średnim i dużym zespole. Jako rozproszony system kontroli wersji, poprzez system push/pull, pomaga programistom stworzyć ekosystem kodu źródłowego, który pomaga zarządzać dużą pulą programistów pracujących nad jednym projektem.

Na przykład powiedzmy, że ufasz 5 deweloperom i pobierasz tylko kody z ich repozytorium. Każdy z tych programistów ma własną sieć zaufania, skąd pobierają kody. Tak więc rozwój opiera się na tej strukturze zaufania programistów, gdzie odpowiedzialność za kod jest dzielona między społeczność programistów.

Oczywiście istnieją inne korzyści, o których mowa w innych odpowiedziach tutaj.

Kilka odpowiedzi nawiązywało do nich, ale chcę zaznaczyć 2 punkty:

1) umiejętność wykonywania selektywnych commitów (na przykład git add --patch). Jeśli twój katalog roboczy zawiera wiele zmian, które nie są częścią tej samej zmiany logicznej, Git bardzo ułatwia utworzenie commita, który zawiera tylko część zmian. Z Subversion jest to trudne.

2) zdolność do zatwierdzania bez upubliczniania zmiany. W Subversion każdy commit jest natychmiast publiczny i zatem nieodwołalne. To znacznie ogranicza zdolność dewelopera do "commit wcześnie, commit często".

Git jest czymś więcej niż tylko VCS; jest również narzędziem do tworzenia łatek. Subversion to tylko VCS.

Myślę, że Subversion jest w porządku.. dopóki nie zaczniesz się scalać.. albo robić coś skomplikowanego.. lub robienie czegokolwiek, co Subversion uważa za skomplikowane (jak wykonywanie zapytań, aby dowiedzieć się, które gałęzie namierzyły konkretny plik, skąd pochodzi Zmiana , wykrywanie kopii i past itp.)...

Nie zgadzam się ze zwycięską odpowiedzią, twierdząc, że główną korzyścią GIT jest praca w trybie offline - z pewnością jest przydatna, ale jest bardziej jak dodatek do mojego przypadku użycia. SVK może pracować w trybie offline również, nadal nie ma dla mnie wątpliwości, w który z nich zainwestować mój czas nauki).

Chodzi o to, że jest niesamowicie wydajny i szybki, a także-po przyzwyczajeniu się do pojęć-bardzo przydatny (tak, w tym sensie: przyjazny dla użytkownika).

Aby uzyskać więcej informacji na temat historii łączenia, zobacz to : używanie git-svn (lub podobnego) * just* do pomocy przy łączeniu svn?

Dzięki temu, że nie musi stale komunikować się z centralnym serwerem, praktycznie każde polecenie uruchamia się w mniej niż sekundę(oczywiście git push / pull/fetch są wolniejsze tylko dlatego, że muszą initalizować połączenia SSH). Rozgałęzianie jest o wiele łatwiejsze (jedno proste polecenie do rozgałęzienia, jedno proste polecenie do scalenia)

Absolutnie uwielbiam być w stanie zarządzać lokalnymi gałęziami mojego kodu źródłowego w Git bez mętnienia wody centralnego repozytorium. W wielu przypadkach pobieram kod z serwera Subversion i uruchamiam lokalne repozytorium Git, aby móc to zrobić. Jest to również świetne, że inicjalizacja repozytorium Git nie zanieczyszcza systemu plików kilkoma irytującymi .foldery svn wszędzie.

A jeśli chodzi o obsługę narzędzi Windows, TortoiseGit radzi sobie bardzo dobrze z podstawami, ale I tak preferuję linię poleceń, chyba że chcę wyświetlić Dziennik. Bardzo podoba mi się sposób, w jaki Tortoise{GIT|SVN} pomaga podczas czytania logów commitów.

To jest złe pytanie. Zbyt łatwo jest skupić się na brodawkach Gita i sformułować argument o tym, dlaczego subversion jest pozornie lepszy, przynajmniej w niektórych przypadkach użycia. Fakt, że git został pierwotnie zaprojektowany jako niskopoziomowy zestaw do kontroli wersji i ma barokowy interfejs zorientowany na programistów Linuksa, ułatwia holy wars zyskanie przyczepności i postrzeganej legitymizacji. Zwolennicy Gita uderzają w bęben z milionami zalet workflow, które chłopaki z svn / align = "left" / Wkrótce cała debata zostanie ujęta w ramy scentralizowanego vs rozproszonego, co służy interesom społeczności narzędzi svn przedsiębiorstwa. Firmy te, które zazwyczaj publikują najbardziej przekonujące artykuły o wyższości subversion w przedsiębiorstwie, zależą od postrzeganej niepewności git i gotowości svn do długoterminowego sukcesu swoich produktów.

Ale tu jest problem: Subversion to architektoniczny ślepy zaułek .

Mając na uwadze, że możesz wziąć git i zbudować scentralizowaną wymianę subversion dość łatwo, pomimo tego, że svn jest ponad dwa razy dłuższy niż svn nigdy nie był w stanie uzyskać nawet podstawowego śledzenia połączeń w pobliżu tak dobrze, jak to robi w git. Jednym z podstawowych powodów jest decyzja projektowa, aby gałęzie były takie same jak katalogi. Nie wiem, dlaczego poszli w tę stronę, to na pewno sprawia, że częściowe kasowanie jest bardzo proste. Niestety uniemożliwia to również śledzenie historia jak należy. Teraz oczywiście powinieneś użyć konwencji układu repozytorium subversion, aby oddzielić gałęzie od zwykłych katalogów, a svn używa pewnych heurystyk, aby działać w codziennych przypadkach użycia. Ale wszystko to jest po prostu papier nad bardzo słabą i ograniczającą niskopoziomową decyzję projektową. Jest w stanie zrobić repozytorium mądry diff (zamiast katalogów mądry diff) jest podstawową i krytyczną funkcjonalnością dla systemu kontroli wersji, i znacznie upraszcza wewnętrzne, co czyni go możliwość tworzenia inteligentniejszych i przydatnych funkcji na nim. Widać w wysiłku, jaki został włożony w rozszerzenie subversion, a jednak jak daleko jest on w tyle od obecnego zbioru nowoczesnych Vcse pod względem podstawowych operacji, takich jak merge resolution.

Oto moja serdeczna i agnostyczna rada dla każdego, kto nadal wierzy, że Subversion jest wystarczająco dobry na najbliższą przyszłość:

Subversion nigdy nie dogoni nowszych Ras Vcsów, które nauczyły się z błędów RCS i CVS; jest to techniczna niemożliwość, chyba że przeinstalują model repozytorium od podstaw, ale wtedy to naprawdę nie byłby svn, prawda? Niezależnie od tego, jak bardzo uważasz, że nie masz możliwości nowoczesnych VCS, twoja ignorancja nie ochroni Cię przed pułapkami Subversion, z których wiele to sytuacje, które są niemożliwe lub łatwo rozwiązane w innych systemach.

Niezwykle rzadko zdarza się, że techniczna niższość rozwiązania jest tak wyraźna, jak tak jest z svn, na pewno nigdy bym nie wypowiedział takiej opinii na temat win-vs-linux czy emacs-vs-vi, ale w tym przypadku jest to tak clearcut, a kontrola źródeł jest tak podstawowym narzędziem w arsenale dewelopera, że uważam, że należy to jednoznacznie stwierdzić. Niezależnie od wymogu używania svn ze względów organizacyjnych, proszę wszystkich użytkowników svn, aby nie pozwalali logicznemu umysłowi konstruować fałszywego przekonania, że bardziej nowoczesne Vcse są użyteczne tylko dla dużych projektów open-source. Niezależnie od Natury jeśli jesteś programistą, będziesz bardziej efektywnym programistą, jeśli nauczysz się używać lepiej zaprojektowanych Vcse, czy to Git, Mercurial, Darcs, czy wielu innych.

Subversion jest bardzo łatwy w użyciu. Nigdy nie znalazłem w ostatnich latach problemu lub że coś nie działa zgodnie z oczekiwaniami. Istnieje również wiele doskonałych narzędzi GUI, a obsługa integracji SVN jest duża.

Z Gitem masz bardziej elastyczny VCS. Możesz go używać tak samo jak SVN ze zdalnym repozytorium, w którym zatwierdzasz wszystkie zmiany. Ale możesz również używać go głównie w trybie offline i tylko od czasu do czasu przesyłać zmiany do zdalnego repozytorium. Ale Git jest bardziej złożony i ma bardziej stroma krzywa uczenia się. Znalazłem się po raz pierwszy zobowiązując się do niewłaściwych gałęzi, tworząc gałęzie pośrednio lub uzyskać komunikaty o błędach z niewiele informacji o błędzie i gdzie muszę szukać w Google, aby uzyskać lepsze informacje. Niektóre proste rzeczy, takie jak zamiana znaczników ($Id$) nie działają, ale GIT ma bardzo elastyczny mechanizm filtrowania i Hooka do scalania własnych skryptów, więc dostajesz wszystko, czego potrzebujesz i więcej, ale potrzebuje więcej czasu i czytania dokumentacji ;)

Jeśli pracujesz głównie offline z lokalnym repozytorium, nie masz kopii zapasowej, jeśli coś zostanie utracone na lokalnym komputerze. Dzięki SVN pracujesz głównie ze zdalnym repozytorium, które jest jednocześnie Twoją kopią zapasową na innym serwerze... Git może działać w ten sam sposób, ale nie było to głównym celem Linusa, aby mieć coś takiego jak SVN2. Został zaprojektowany z myślą o programistach jądra Linuksa i potrzebach rozproszonego systemu kontroli wersji.

Czy Git jest lepszy od SVN? Deweloperzy który potrzebuje tylko trochę historii wersji i mechanizmu kopii zapasowej mają dobre i łatwe życie z SVN. Programiści pracujący często z Oddziałami, testujący więcej wersji w tym samym czasie lub pracujący głównie w trybie offline mogą skorzystać z funkcji Git. Istnieje kilka bardzo przydatnych funkcji, takich jak ukrywanie nie Znalezione w SVN, które mogą ułatwić życie. Ale z drugiej strony nie wszyscy ludzie będą potrzebować wszystkich funkcji. Więc nie mogę zobaczyć zmarłych z SVN.

Git potrzebuje lepszej dokumentacji i błędu raportowanie musi być bardziej pomocne. Również istniejące przydatne Gui są rzadko. Tym razem znalazłem tylko 1 GUI dla Linuksa z obsługą większości funkcji Git (git-cola). Integracja Eclipse działa, ale nie jest oficjalnie wydana i nie ma oficjalnej strony aktualizacji (tylko jakaś zewnętrzna strona aktualizacji z okresowymi kompilacjami z trunku http://www.jgit.org/updates ) Tak więc najbardziej preferowanym sposobem użycia Gita w dzisiejszych czasach jest linia komend.

Eric Sink z SourceGear napisał serię artykułów na temat różnic między rozproszonymi i niepodzielonymi systemami kontroli wersji. Porównuje plusy i minusy najpopularniejszych systemów kontroli wersji. Bardzo ciekawa lektura.
Artykuły można znaleźć na jego blogu, www.ericsink.com : {]}

• Przeczytaj Diffs

• Git jest C narzędzi kontroli wersji

• O braku szacunku dla niezmienności Git i najlepsze praktyki dla DVCS

• DVCS i dag, Część 1

• DVCS i dag, część 2

• DVC i śledzenie błędów

• Scalanie historii, dag i Darcs

• Dlaczego Git jest tak szybki?

• Mercurial, Subversion i Wesley Snipes

Dla osób poszukujących dobrego GUI Git, Syntevo SmartGit może być dobrym rozwiązaniem. Jego własnościowe, ale wolne do użytku niekomercyjnego, działa na systemach Windows / Mac/Linux, a nawet obsługuje SVN używając, jak sądzę, jakiegoś mostu git-svn.

Http://subversion.wandisco.com/component/content/article/1/40.html

Myślę, że dość bezpiecznie jest powiedzieć, że wśród deweloperów, argument SVN Vs. Git szaleje już od jakiegoś czasu, a każdy ma swój własny pogląd na to, co jest lepsze. Zostało to nawet poruszone w pytaniach podczas naszego webinarium na temat Subversion w 2010 roku i Później.

Hyrum Wright, nasz dyrektor Open Source i prezes Subversion Corporation mówi o różnice między Subversion i Git, wraz z innymi rozproszonymi systemami kontroli wersji (DVC).

On również mówi o nadchodzących zmianach w Subversion, takich jak Working Copy Next Generation (WC-NG), które jego zdaniem spowodują, że wielu użytkowników Gita przekonwertuje się z powrotem do Subversion.

Obejrzyj jego film i daj nam znać, co myślisz, komentując ten blog lub publikując na naszych forach. Rejestracja jest prosta i zajmie tylko chwilę!

Git w Windows jest teraz dość dobrze wspierany.

Sprawdź GitExtensions = http://code.google.com/p/gitextensions/

I podręcznik dla lepszego środowiska Windows Git.

Ostatnio mieszkałem w Git land i lubię go dla osobistych projektów, ale nie byłbym w stanie przełączyć projektów pracy na niego jeszcze z Subversion biorąc pod uwagę zmianę w myśleniu wymaganych od personelu, bez żadnych pilnych korzyści. Co więcej, największy projekt, który prowadzimy wewnętrznie, jest bardzo zależny od svn: externals, który z tego, co widziałem do tej pory, nie działa tak ładnie i bezproblemowo w Git.

Po pierwsze, współbieżna Kontrola wersji wydaje się łatwym problemem do rozwiązania. Wcale nie. W każdym razie...

SVN jest dość nieintuicyjny. Git jest jeszcze gorszy. [sarkastyczne spekulacje] może to być spowodowane tym, że deweloperzy, którzy podobnie jak trudne problemy, takie jak współbieżna Kontrola wersji, nie mają dużego zainteresowania tworzeniem dobrego interfejsu użytkownika. [/sarkastyczne-spekulacje]

Zwolennicy SVN uważają, że nie potrzebują rozproszonego systemu kontroli wersji. Też tak myślałem. ale teraz, gdy używamy Git / align = "left" / Teraz Kontrola wersji działa dla mnie i zespołu / projektu, a nie tylko dla projektu. Kiedy potrzebuję gałązki, rozgałęziam się. Czasami jest to gałąź, która ma odpowiednią gałąź na serwerze, a czasami nie. Nie wspominając o wszystkich innych zaletach, które będę musiał studiować (po części dzięki tajemniczemu i absurdalnemu braku interfejsu użytkownika, który jest nowoczesnym systemem kontroli wersji).

Dlaczego uważam, że Subversion jest lepszy niż Git (przynajmniej dla projektów, nad którymi pracuję), głównie ze względu na jego użyteczność i prostszy przepływ pracy:

Http://www.databasesandlife.com/why-subversion-is-better-than-git/