Dlaczego Git jest lepszy od Subversion?

393

Używam Subversion od kilku lat i po użyciu SourceSafe , po prostu uwielbiam Subversion. W połączeniu z TortoiseSVN nie mogę sobie wyobrazić, jak mogłoby być lepiej.

Jednak rośnie liczba programistów twierdzących, że Subversion ma problemy i że powinniśmy przejść na nowy rodzaj rozproszonych systemów kontroli wersji, takich jak Git .

Jak Git poprawia się po Subversion?

Peter Mortensen
źródło

Odpowiedzi:

548

Git nie jest lepszy niż Subversion. Ale też nie jest gorzej. To jest inne.

Najważniejsza różnica polega na tym, że jest ona zdecentralizowana. Wyobraź sobie, że jesteś programistą w drodze, rozwijasz się na swoim laptopie i chcesz mieć kontrolę nad źródłem, aby móc cofnąć się o 3 godziny.

Z Subversion masz problem: repozytorium SVN może znajdować się w miejscu, do którego nie możesz dotrzeć (w twojej firmie i nie masz w tej chwili internetu), nie możesz zatwierdzić. Jeśli chcesz zrobić kopię swojego kodu, musisz go dosłownie skopiować / wkleić.

Z Git nie masz tego problemu. Twoja lokalna kopia jest repozytorium i możesz się do niej zobowiązać i uzyskać wszystkie korzyści kontroli źródła. Gdy odzyskasz łączność z głównym repozytorium, możesz dokonać na nim zgody.

Na początku wygląda to dobrze, ale należy pamiętać o dodatkowej złożoności tego podejścia.

Git wydaje się być „nową, błyszczącą, fajną” rzeczą. Nie jest to wcale złe (istnieje powód, dla którego Linus napisał to dla rozwoju jądra Linuksa), ale czuję, że wiele osób wskakuje na pociąg "Distributed Source Control" tylko dlatego, że jest nowy i jest napisany przez Linusa Torvaldsa, w rzeczywistości wiedząc dlaczego / jeśli jest lepiej.

Subversion ma problemy, ale także Git, Mercurial, CVS, TFS lub cokolwiek innego.

Edycja: Więc ta odpowiedź ma już rok i wciąż generuje wiele pozytywnych opinii, więc pomyślałem, że dodam więcej wyjaśnień. W ciągu ostatniego roku od napisania tego tekstu Git zyskał duży rozpęd i wsparcie, zwłaszcza że strony takie jak GitHub naprawdę się rozkręciły. Obecnie używam Git i Subversion i chciałbym podzielić się osobistymi spostrzeżeniami.

Po pierwsze, Git może być na początku bardzo mylący, gdy pracuje zdecentralizowany. Co to jest pilot? i jak poprawnie skonfigurować początkowe repozytorium? są dwa pytania, które pojawiają się na początku, szczególnie w porównaniu do prostego „SVNADMIN” SVN, „Git init” Gita może przyjmować parametry - gołe i - udostępnione, co wydaje się być „właściwym” sposobem na skonfigurowanie scentralizowanego magazyn. Są ku temu powody, ale dodaje to złożoności. Dokumentacja polecenia „checkout” jest bardzo myląca dla osób, które się zmieniają - „właściwym” sposobem wydaje się być „git clone”, podczas gdy „git checkout” wydaje się zmieniać gałęzie.

Git NAPRAWDĘ świeci, gdy jesteś zdecentralizowany. Mam w domu serwer i laptopa w podróży, a SVN po prostu nie działa tutaj dobrze. W przypadku SVN nie mogę mieć lokalnej kontroli źródła, jeśli nie jestem podłączony do repozytorium (Tak, wiem o SVK lub o sposobach kopiowania repozytorium). W przypadku Git jest to i tak tryb domyślny. Jest to jednak dodatkowe polecenie (git commit zatwierdza lokalnie, podczas gdy git push master master wypycha gałąź master do zdalnego o nazwie „origin”).

Jak powiedziano powyżej: Git dodaje złożoności. Dwa tryby tworzenia repozytoriów: pobieranie kontra klonowanie, zatwierdzanie kontra wypychanie ... Musisz wiedzieć, które polecenia działają lokalnie, a które z „serwerem” (zakładam, że większość ludzi nadal lubi centralne „repozytorium główne” ).

Oprzyrządowanie jest nadal niewystarczające, przynajmniej w systemie Windows. Tak, istnieje dodatek Visual Studio AddIn, ale nadal używam git bash z msysgit.

Zaletą SVN jest to, że jest DUŻO łatwiejszy do nauczenia: istnieje Twoje repozytorium, wszystkie zmiany w stosunku do niego, jeśli wiesz, jak tworzyć, zatwierdzać i kasować, i jesteś gotowy do pracy i możesz odbierać takie rzeczy, jak rozgałęzienie, aktualizacja itp. Później na.

Git ma tę zaletę, że jest DUŻO bardziej odpowiedni, jeśli niektórzy programiści nie zawsze są podłączeni do głównego repozytorium. Ponadto jest znacznie szybszy niż SVN. Z tego, co słyszę, obsługa gałęzi i łączenie jest znacznie lepsza (czego należy się spodziewać, ponieważ są to główne powody, dla których została napisana).

Wyjaśnia to również, dlaczego zyskuje tak dużo szumu w Internecie, ponieważ Git doskonale nadaje się do projektów Open Source: po prostu rozwidlaj go, zatwierdzaj zmiany we własnym Fork, a następnie poproś oryginalnego opiekuna projektu o wycofanie zmian. W przypadku Git to po prostu działa. Naprawdę, wypróbuj to na Githubie, to magia.

Widzę także mosty Git-SVN: Centralne repozytorium jest repozytorium Subversion, ale programiści lokalnie współpracują z Git, a następnie most przesyła swoje zmiany do SVN.

Ale nawet z tym długim dodatkiem wciąż podtrzymuję moje podstawowe przesłanie: Git nie jest ani lepszy ani gorszy, jest po prostu inny. Jeśli potrzebujesz „Kontroli źródła offline” i chęci poświęcenia dodatkowego czasu na jej naukę, to fantastyczne. Ale jeśli masz ściśle scentralizowaną kontrolę źródła i / lub starasz się wprowadzić kontrolę źródła w pierwszej kolejności, ponieważ twoi współpracownicy nie są zainteresowani, to prostota i doskonałe oprzyrządowanie (przynajmniej w systemie Windows) SVN świeci.

Michael Stum
źródło
70
Ferrari nie jest lepsze niż Hyundai. Ale też nie jest gorzej. To jest inne. (Co? Nie
patrz
219
Nie, nie zrobiłeś. Ferrari jest niepraktyczne, drogie, spragnione i nie da ci lepszej drogi od A do B, jeśli mieszkasz w mieście takim jak Nowy Jork lub Paryż - wolałbym Hyundai w wielu miejscach, również dlatego, że zadrapanie jest znacznie mniej dotkliwe. Ale dla każdego własnego - Ferrari ma (bardzo niewiele) zalet ...
Michael Stum
50
Dystrybucja nie jest jedyną różnicą między Subversion a Git. Nie powoduje to również żadnej złożoności, chyba że korzystasz z wielu repozytoriów. Istnieje wiele zalet używania Git zamiast Subversion, ale tylko kilka (w większości nieznacznych) wad. Git jest używany, ponieważ jest dobry, a nie błyszczący.
wrzesień
6
Moje doświadczenia z git nie są dokładnie „objawieniem zmieniającym życie”. Uważam to za świetne narzędzie, gdy działa, a kiedy nie, wydaje się raczej niedopolerowane. Nie byłem pod wrażeniem debugowania takich rzeczy jak Pytanie 1052882 i mimo że jest to wyraźnie problem RTFM: Uważam, że git (i wszelkie inne rozproszone vcs) są bardziej skomplikowane niż scentralizowane i rozważę użycie go w scentralizowanych środowiskach . Ale z drugiej strony jestem głównie programistą Windows, a narzędzia są nadal niedojrzałe w systemie Windows w porównaniu do SVN.
Michael Stum
5
Analizujesz tylko aspekt dystrybucji w porównaniu. Powiem ci dlaczego. Ponieważ chcesz tylko udostępniać kod. Git i SVN to coś więcej. Czy kiedykolwiek tagowałeś, rozgałęziałeś, łączyłeś, rozwiązywałeś konflikty, kopiowałeś łatki między oddziałami? Myślę, że twoja analiza jest po prostu wadliwa. W tych aspektach git jest DUŻO potężnym narzędziem. Nie wspominając już o rzeczach, które git może, a SVN nie może, takich jak zgniatanie, rozrywanie, poprawianie, bazowanie, zbieranie wiśni i wiele innych rzeczy.
mschonaker,
145

Dzięki Git możesz robić praktycznie wszystko offline, ponieważ każdy ma swoje własne repozytorium.

Tworzenie oddziałów i łączenie między oddziałami jest naprawdę łatwe.

Nawet jeśli nie masz uprawnień do zatwierdzania projektu, możesz nadal mieć własne repozytorium online i publikować „żądania wypychania” swoich poprawek. Każdy, kto lubi twoje łatki, może wciągnąć je do swojego projektu, w tym oficjalni opiekunowie.

Rozwidlenie projektu, zmodyfikowanie go i wciąż scalanie poprawek z gałęzi HEAD jest banalne.

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

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 będzie go obsługiwał.

Wreszcie jest GitHub , świetna strona do przechowywania repozytoriów Git.

Wady Git:

  • jest znacznie trudniej się nauczyć, ponieważ Git ma więcej pojęć i więcej poleceń.
  • wersje nie mają numerów wersji jak w wersji subversion
  • wiele poleceń Gita jest tajemniczych, a komunikaty o błędach są bardzo nieprzyjazne dla użytkownika
  • brakuje mu dobrego GUI (takiego jak świetny TortoiseSVN )
Michiel de Mare
źródło
31
Chociaż nauka całego Gita byłaby znacznie trudniejsza, podstawy są prawie identyczne. Zakres nauki nie jest tak stromy, dopóki nie przejdziesz do bardziej zaawansowanych rzeczy, których SVN po prostu i tak nie jest w stanie.
sebnow
10
+1 dla mnie. Myślę, że wielu programistów zapomina, że ​​gitowi brakuje czegoś takiego jak TortoiseSVN i że nie tylko programiści używają kontroli wersji. Drżę na myśl o konieczności wyjaśnienia (i wsparcia) rozproszonej kontroli wersji naszym programistom używającym SVN | TortoiseSVN!
si618
7
kolejna wada - musisz mieć pełną kopię repozytorium, nie możesz pracować na częściach (co ma znaczenie, jeśli masz duże, jak wiele korporacji)
gbjbaanb
3
Uwielbiam git, ale zajęło mi około sześciu miesięcy codziennego używania, aby naprawdę go skutecznie używać. Biorąc to pod uwagę, używam kombinacji powłoki git (wiersza polecenia) z msysgit, git gui i gitk z msysgit i TortoiseGit. Myślę, że TortoiseGit jest świetny, ale nie rozumiem, dlaczego więcej osób go nie używa. Wiem, że opiekunowie msysgit nie lubią TortoiseGit z różnych powodów, niektóre z nich są ideologiczne i może to mieć z tym coś wspólnego. TortoiseGit jest dobrze strzeżoną tajemnicą!
Jim Raden,
2
Zgadzam się. Używam zarówno SVN, jak i GIT (od około 6 miesięcy). Naprawdę kocham git bardziej niż kiedykolwiek SVN. Nauczenie się tego zajmuje tylko trochę czasu. Największy skok dla mnie (moment, w którym zobaczyłem światło: P), to moment, kiedy w końcu zdałem sobie sprawę, że muszę przestać próbować używać GIT tak, jak działa SVN. Potem wszystko poszło na swoim miejscu;)
Blizz
110

Inne odpowiedzi wykonały dobrą robotę, wyjaśniając podstawowe cechy Git (które są świetne). Ale jest też tak wiele małych sposobów, że Git zachowuje się lepiej i pomaga utrzymać moje życie bardziej rozsądne. Oto kilka małych rzeczy:

  1. Git ma polecenie „wyczyść”. SVN rozpaczliwie potrzebuje tego polecenia, biorąc pod uwagę, jak często zrzuca dodatkowe pliki na dysku.
  2. Git ma polecenie „bisect”. To miłe.
  3. SVN tworzy katalogi .svn w każdym folderze (Git tworzy tylko jeden katalog .git). Każdy skrypt, który napiszesz i każdy grep, który zrobisz, będzie musiał zostać napisany, aby zignorować te katalogi .svn. Potrzebujesz także całego polecenia („eksport svn”), aby uzyskać zdrową kopię swoich plików.
  4. W SVN każdy plik i folder może pochodzić z innej wersji lub oddziału. Z początku fajnie jest mieć tę swobodę. Ale tak naprawdę oznacza to, że istnieje milion różnych sposobów, aby lokalna kasa została całkowicie zepsuta. (na przykład jeśli „przełącznik svn” nie powiedzie się w połowie lub źle wprowadzisz polecenie). A najgorsze jest to, że jeśli kiedykolwiek zdarzy się sytuacja, w której niektóre twoje pliki pochodzą z jednego miejsca, a niektóre z innego, „status svn” powie ci, że wszystko jest normalne. Musisz zrobić „svn info” dla każdego pliku / katalogu, aby dowiedzieć się, 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 powiedzieć SVN za każdym razem, gdy coś przenosisz lub usuwasz. Git po prostu to rozwiąże.
  6. Ignorowanie semantyki jest łatwiejsze w Git. Jeśli zignorujesz wzorzec (taki jak * .pyc), zostanie on zignorowany dla wszystkich podkatalogów. (Ale jeśli naprawdę chcesz zignorować coś dla jednego katalogu, możesz). W przypadku SVN wydaje się, że nie ma łatwego sposobu na zignorowanie wzorca we wszystkich podkatalogach.
  7. Kolejny element polegający na ignorowaniu plików. Git umożliwia ustawienie „prywatnego” ignorowania ustawień (przy użyciu pliku .git / info / exclude), co nie wpłynie na nikogo innego.
andy
źródło
2
Ogłoszenie. 7. W nowoczesnym git możesz również ustawić „prywatne” ustawienie ignorowania dla użytkownika, używając zmiennej konfiguracyjnej core.excludesFile w ~ .gitignore (zobacz man git-config).
Jakub Narębski
3
Re # 5: Chociaż jest to zwykle prawda, Git czasami to popieprza. Przynajmniej w przypadku Subversion problemy związane z przenoszeniem lub usuwaniem są prawie zawsze PEBKAC. Chociaż miło jest mieć automatyczne śledzenie przenoszenia / usuwania, nadal doceniam możliwość wyraźnego określenia, co robię z plikami w repozytorium, nawet jeśli nie muszę go używać.
Chris Charabaruk
8
@Chris: Możesz to zrobić wyraźnie: git mvi git rm.
R. Martinho Fernandes,
2
Chciałbym również zobaczyć opcję jednego katalogu .svn na kopię roboczą, ale dla przypomnienia: Dla nr 3: Większość narzędzi (domyślnie) zignoruje katalogi .svn. Dla # 6: Możesz ustawić właściwości rekurencyjnie.
si618,
6
3: „Pojedynczy katalog .svn” będzie dostępny w SVN 1.7, gdy WC-NG zostanie wdrożony. 1: Aby uzyskać czyszczenie SVN, „eksportuj” ponad toaletę. 5: nie jest to takie proste, jeśli zmienisz nazwę pliku, rozpoznaje go i zachowuje historię, lub traktuje jako dodawanie i usuwanie w katalogu ?. 6/7: svn ma globalne ignorowanie ustawień klienta klienta.
gbjbaanb
56

Dlaczego Git jest lepszy niż X ” przedstawia różne zalety i wady Git w porównaniu do innych SCM.

Krótko:

  • Git śledzi zawartość, a nie pliki
  • Oddziały są lekkie, a łączenie jest łatwe , a mam na myśli naprawdę łatwe .
  • Jest dystrybuowany, w zasadzie każde repozytorium jest oddziałem. Moim zdaniem znacznie łatwiej jest rozwijać się jednocześnie i współpracować niż z Subversion. Umożliwia także programowanie offline .
  • To narzuca żadnego przepływu pracy , jak widać na powyższej połączonej stronie , istnieje wiele przepływów pracy z Git. Przepływ pracy w stylu Subversion można łatwo naśladować.
  • Repozytoria Git są dużo mniejszy rozmiar niż repozytoria Subversion. Jest tylko jeden katalog „.git”, w przeciwieństwie do kilkudziesięciu repozytoriów „.svn” (uwaga: Subversion 1.7 i nowsze używają teraz jednego katalogu, takiego jak Git.)
  • The inscenizacji jest niesamowity, pozwala zobaczyć zmiany, które popełnisz, dokonać częściowych zmian i zrobić różne inne rzeczy.
  • Ukrywanie jest nieocenione, gdy wykonujesz „chaotyczny” rozwój lub po prostu chcesz naprawić błąd, gdy wciąż pracujesz nad czymś innym (w innej gałęzi).
  • Możesz przepisać historię , która jest świetna do przygotowywania zestawów poprawek i naprawiania błędów ( nadaje się przed opublikowaniem zatwierdzeń)
  • … I wiele więcej.

Istnieją pewne wady:

  • Nie ma jeszcze wielu dobrych GUI. Jest nowy, a Subversion istnieje już od dłuższego czasu, więc jest to naturalne, ponieważ opracowywanych jest kilka interfejsów. Niektóre dobre to TortoiseGit i GitHub dla komputerów Mac .
  • Częściowe pobranie / klonowanie repozytoriów nie jest obecnie możliwe (czytam, że jest w fazie rozwoju). Istnieje jednak obsługa submodułów. Git 1.7+ obsługuje rzadkie płatności .
  • Może być trudniej się nauczyć, chociaż nie znalazłem tego (około rok temu). Git niedawno ulepszył interfejs i jest bardzo 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

Git naprawdę świeci, rozgałęzia się i współpracuje z innymi ludźmi.

sebnow
źródło
8
Mówisz, że GIT śledzi zawartość, a nie pliki. Odkryłem, że SVN również to robi: właśnie dokonałem zmian w pliku i zapisałem go. SVN pokazał plik jako czerwony (zmieniony). Potem cofnąłem edytor i zapisałem go ponownie. Następnie SVN zaktualizował status na zielony (niezmieniony), nawet jeśli plik został zmieniony (data zmiany nowsza), ale SVN rozpoznał, że treść nie została zmieniona w stosunku do oryginału.
awe
czy svn śledzi zmiany między plikami?
Seun Osewa
12
@awe, to się nazywa śledzenie plików. spróbuj zmienić nazwę pliku lub przenieść go gdzie indziej ręcznie [ta sama treść, nowy plik (z powodu nowej ścieżki / nazwy)]: czy SVN będzie wiedział, że to ten sam plik i zachowa poprzednie niezliczone poprawki, które wprowadziłeś? nie, chyba nie.
Filip Dupanović
54

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

ESV
źródło
12
Rozmowa Linusa jest fajna do oglądania. Brutalnie zrywa scentralizowane systemy kontroli wersji, takie jak Subversion i CVS. Jednak wykład youtube.com/watch?v=8dhZ9BXQgc4 Randala Schwartza jest bardziej konstruktywny, bardziej pouczający i przekonujący.
zginać
2
Ten też jest całkiem niezły. Pochodzi z jednego z zatwierdzających git i wyjaśnia wiele zaawansowanych funkcji, takich jak dzielenie dużych zmian na mniejsze. youtube.com/watch?v=j45cs5_nY2k
schoetbi
Podoba mi się to wideo Linusa Torvaldsa, ale sugeruje, że git jest rozpowszechniany, a nie scentralizowany, a to po prostu źle. Można go używać w sposób rozproszony lub w sposób scentralizowany. Możesz mieć jedno centralne repozytorium, do którego wszyscy się zobowiązują, tak jak w SVN. Po prostu nie musisz tego robić w ten sposób.
MatrixFrog,
@MatrixForog: Myślę, że w tym przypadku „zdecentralizowany” nie jest przeciwieństwem „scentralizowany”, ale naprawdę nadzbiorem. To jest jak „mobilne” i „nieruchome” - tylko dlatego, że coś jest „mobilne” nie mnie, nie może stać w miejscu.
Tikhon Jelvis
26

Cóż, jest rozpowszechniany. Benchmarki wskazują, że jest znacznie szybszy (biorąc pod uwagę jego rozproszony charakter, operacje takie jak diffs i logi są wszystkie lokalne, więc oczywiście jest niesamowicie szybszy w tym przypadku), a foldery robocze są mniejsze (co wciąż zdumiewa mnie).

Kiedy pracujesz nad wersją subversion lub jakimkolwiek innym systemem kontroli wersji klient / serwer, zasadniczo tworzysz kopie robocze na swoim komputerze, sprawdzając wersje. Jest to migawka w czasie, jak wygląda repozytorium. Aktualizujesz kopię roboczą za pomocą aktualizacji i aktualizujesz repozytorium za pomocą zatwierdzeń.

Dzięki rozproszonej kontroli wersji nie masz migawki, ale cała baza kodu. Chcesz zrobić różnicę z 3-miesięczną wersją? Nie ma problemu, 3-miesięczna wersja wciąż jest na twoim komputerze. To nie tylko oznacza, że ​​rzeczy są znacznie szybsze, ale jeśli nie masz połączenia z serwerem centralnym, nadal możesz wykonywać wiele operacji, do których jesteś przyzwyczajony. Innymi słowy, masz nie tylko migawkę danej wersji, ale całą bazę kodu.

Można by pomyśleć, że Git zajmie sporo miejsca na dysku twardym, ale z kilku testów, które widziałem, w rzeczywistości zajmuje mniej. Nie pytaj mnie jak. Mam na myśli, że został zbudowany przez Linusa, on chyba coś wie o systemach plików.

Karl Seguin
źródło
1
Powodem, dla którego Git może zająć mniej miejsca na dysku dla pełnego repozytorium niż Subversion dla samej kasy, jest to, że Subversion przechowuje „nieskazitelną kopię”, aby sprawić, że „svn diff” (porównanie z ostatnią wersją) działa ... i że repozytorium git jest skompresowane (i deltaified) ).
Jakub Narębski
3
Nie dziwię się, że „foldery robocze” (tj. Repozytoria) są mniejsze niż kopie robocze svn, ponieważ nawet repozytoria svn są mniejsze niż kopie robocze svn.
R. Martinho Fernandes,
22

Główne punkty, które lubię w DVCS, to:

  1. Możesz popełniać zepsute rzeczy. To nie ma znaczenia, ponieważ inne narody ich nie zobaczą, dopóki ich nie opublikujesz. Czas publikacji różni się od czasu zatwierdzenia.
  2. Z tego powodu możesz częściej popełniać błędy.
  3. Możesz połączyć pełną funkcjonalność. Ta funkcjonalność będzie miała własną gałąź. Wszystkie zatwierdzenia tej gałęzi będą powiązane z tą funkcją. Możesz to zrobić za pomocą CVCS, jednak z DVCS jest to ustawienie domyślne.
  4. Możesz przeszukać swoją historię (dowiedzieć się, kiedy funkcja się zmieniła)
  5. Możesz cofnąć ściąganie, jeśli ktoś zepsuje główne repozytorium, nie musisz naprawiać błędów. Po prostu wyczyść scalenie.
  6. Kiedy potrzebujesz kontroli źródła w dowolnym katalogu, wykonaj: git init. i możesz zatwierdzać, cofać zmiany itp.
  7. Jest szybki (nawet w systemie Windows)

Głównym powodem stosunkowo dużego projektu jest poprawiona komunikacja stworzona przez punkt 3. Inne to miłe bonusy.

Emmanuel Caradec
źródło
Myślę, że punkt 1 zamierza powiedzieć „inni ludzie nie zobaczą ich, dopóki nie opublikujesz ” (lub „push”).
jackr
+1 „Możesz popełnić zepsute rzeczy”. jest głównym powodem, dla którego rozważam przejście na git z svn. Zawsze nienawidzę, kiedy jestem w połowie tworzenia ciężkiego bloku kodu i nie mam siatki bezpieczeństwa VCS (po prostu dlatego, że moje modyfikacje jeszcze nie działają, więc nie wolno mi zatwierdzać).
András Szepesházi
15

Zabawne jest to, że prowadzę projekty w repozytoriach Subversion, ale uzyskuję do nich dostęp za pomocą polecenia Git Clone.

Proszę przeczytać Develop with Git w Google Code Project

Chociaż Google Code natywnie mówi Subversion, możesz łatwo używać Git podczas programowania. Wyszukiwanie „git svn” sugeruje, że ta praktyka jest powszechna i my również zachęcamy do eksperymentowania z nią.

Korzystanie z Git w repozytorium Svn daje mi korzyści:

  1. Mogę pracować w rozproszeniu na kilku maszynach, zatwierdzanie i wyciągając z nich oraz
  2. Mam centralny backup/public repozytorium SVN do sprawdzenia przez innych
  3. I mogą swobodnie korzystać z Git na własny użytek
Andre Bossard
źródło
3
to jest trochę nieaktualne, kod Google robi merkurialny, więc nie jest już potrzebny ten hack
Sam Saffron
@Sam, chyba że lubisz git i / lub nie lubisz rtęci.
MatrixFrog,
11

Wszystkie odpowiedzi tutaj są zgodne z oczekiwaniami, zorientowane na programistę, ale co się stanie, jeśli Twoja firma używa 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 znajdować się blisko kodu, a nie w innym CMS. Większość programistów nie pracuje w izolacji - pracujemy dla firm w ramach zespołu.

Mając to na uwadze, porównaj łatwość użycia, zarówno w narzędziach klienta, jak i szkoleniu, między Subversion a git. Nie widzę scenariusz, w którym każdy rozproszony system kontroli wersji będzie łatwiejszy w użyciu lub wyjaśnienie nieprogramiście. Chciałbym, aby udowodniono, że się mylę, ponieważ wtedy byłbym w stanie ocenić git i mieć nadzieję, że zostanie zaakceptowany przez ludzi, którzy potrzebują kontroli wersji, którzy nie są programistami.

Nawet wtedy, gdy zarząd zapytałby nas, dlaczego powinniśmy przejść ze scentralizowanego na rozproszony system kontroli wersji, ciężko byłoby mi podać szczerą odpowiedź, ponieważ jej nie potrzebujemy.

Oświadczenie: zainteresowałem się Subversion bardzo wcześnie (około v0.29), więc oczywiście jestem stronniczy, ale firmy, dla których pracowałem od tego czasu, czerpią korzyści z mojego entuzjazmu, ponieważ zachęciłem i poparłem jego użycie. Podejrzewam, że tak dzieje się z większością firm produkujących oprogramowanie. Przy tylu programistach, którzy wskakują na modę Git, zastanawiam się, ile firm nie skorzysta z zalet kontroli wersji poza kodem źródłowym? Nawet jeśli masz oddzielne systemy dla różnych zespołów, tracisz niektóre korzyści, takie jak (ujednolicona) integracja śledzenia problemów, jednocześnie zwiększając wymagania dotyczące konserwacji, sprzętu i szkoleń.

Si.
źródło
IMHO, jest to jedyny uzasadniony powód do faworyzowania SVN. Krótko mówiąc, łatwiej jest wytłumaczyć nieprogramiście, czyli osobie, która spodziewała się używać go w sposób liniowy i unikać złożonych (= rzeczywistych) scenariuszy VC: konflikty, 3-kierunkowe połączenia, rozgałęzienia. i tak nigdy nie chcę pozwolić VCS na scalenie pliku prezentacji PowerPoint.
inger
2
„Większość programistów nie działa w izolacji” wydaje się sugerować, że księgowi / marketingowcy musieliby korzystać z tego samego repozytorium, w którym przechowywany jest kod źródłowy. Nie widzę korzyści z tego; niektóre moje byłe firmy chciały ustandaryzować takie rzeczy, ale nieuchronnie się to nie udało. Myślę, że uproszczone podejście może być świetne dla menedżera, ale nadmierne uproszczenie dla zespołów programistów - więc ujednolicenie ich prowadzi do złego kompromisu.
inger
W przypadku dokumentów towarzyszących oprogramowaniu masz rację - powinny być one razem wersjonowane. Odkryłem, że ci o wiele mniej niż ludzie początkowo myślą (w końcu wyrzuciliśmy ogromne drzewo dokumentów z repozytorium źródłowego). Ponadto istnieje wiele sposobów na uproszczenie przepływu pracy twórców technologii itp., Jeśli jest to problem (nie powinien).
inger
2
@inger Nie sądzę, żebyś mógł powiedzieć „to jedyny uzasadniony powód”, obsługa narzędzi AFAIK dla Subversion jest znacznie lepsza niż Git, np. TortoiseSVN i integracja z Visual Studio i Java IDE jak Eclipse. To może nie być problem dla ciebie, ale z pewnością jest dla nas. Nie wspomniałem o tym w mojej odpowiedzi, ponieważ jest to osobny problem.
si618
1
@Keyo, tak, to prawda, że ​​nie-programiści zajmą trochę czasu, aby uzyskać Subversion, ale myślę, że potrwają dłużej z git lub Hg. Wiki są świetne, jeśli są utrzymywane, ale z mojego doświadczenia wynika, że ​​programiści są bardziej skłonni do przechowywania dokumentów związanych z kodem źródłowym, jeśli są blisko tego kodu źródłowego. Zgadzam się z inger, że nie ma tylu dokumentów, które pasują do tej kategorii, ale z pewnością istnieją. To ciekawe, że git / Hg są najlepszym narzędziem do tego zadania, to ogólne stwierdzenie, które prawdopodobnie nie jest prawdziwe we wszystkich okolicznościach, czy git i Hg mają tak dobrą integrację jak SVN?
si618
9

Subversion jest wciąż znacznie częściej stosowanym systemem kontroli wersji, co oznacza, że ​​ma lepszą obsługę 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 Michaelem : Git nie jest lepszy ani gorszy od Subversion, jest inny.

neu242
źródło
Ale teraz, po kilku latach intensywnego używania gita, muszę się ze sobą nie zgodzić: Git jest znacznie lepszy niż Subversion. Przynajmniej raz przejdziesz przez nieprzyjazną składnię Gita.
neu242,
8

Jedną z rzeczy, które mnie denerwują w SubVersion, jest to, że umieszcza własny folder w każdym katalogu projektu, podczas gdy git umieszcza tylko jeden w katalogu głównym. To nie jest to nic wielkiego, ale takie małe rzeczy, które sumują się.

Oczywiście SubVersion ma Tortoise, co jest [zwykle] bardzo miłe.

Swilliams
źródło
5
katalogi .svn wkrótce znikną, prawdopodobnie z
wersją 1.7
8

David Richards Blog WANdisco o Subversion / GIT

Pojawienie się GIT przyniosło ze sobą rasę fundamentalistów DVCS - „Gitteronów” - którzy uważają, że wszystko inne niż GIT to bzdury. Wydaje się, że Gitteroni uważają, że inżynieria oprogramowania odbywa się na ich własnej wyspie i często zapominają, że większość organizacji nie zatrudnia wyłącznie starszych inżynierów oprogramowania. To w porządku, ale nie tak myśli reszta rynku i cieszę się, że mogę to udowodnić: GIT, w ostatnim wyglądzie miał mniej niż trzy procent rynku, podczas gdy Subversion ma około pięciu milionów użytkowników i około połowy cały rynek.

Problem, który widzieliśmy, polegał na tym, że Gitteroni strzelali (tanie) strzały w Subversion. Tweety typu „Subversion jest takie [powolne / gówniane / restrykcyjne / nie pachnie dobrze / patrzy na mnie w zabawny sposób] a teraz mam GIT i [wszystko działa w moim życiu / moja żona zaszła w ciążę / mam dziewczynę po 30 lat próbowania / Wygrałem sześć razy na stole do blackjacka]. Dostajesz obraz.

Elaine Murphy
źródło
1
Zauważ, że David Richards może być bezstronny: produkt, który tworzy opiera się na Subversion (lub pomysłach Subversion), więc oczywiście byłby pro-Subversion i anty-Git.
Jakub Narębski,
2
Jak na ironię, Git został stworzony specjalnie, ponieważ inżynieria oprogramowania nie dzieje się na wyspach. Ten cytat jest kretyński.
Ben Collins,
Chociaż używam git, byłbym również bardzo szczęśliwy, mogąc pracować z każdym przyzwoitym DVCS, takim jak na przykład Mercurial. Zdobycie popularności koncepcji DVCS zajmuje dużo czasu, a teraz widzę, że ogromna liczba projektów open source przeszła na git.
Keyo
Malując krytyków SVN jako fundamentalistów, David przesuwa się w stronę fundamentalnej kwestii: architektura wywrotowa jest ślepą uliczką. Nie chodzi o to, że git jest kompletnym VCS, ma na pewno brodawki, ale git, mercurial, darcs i wiele innych VCS ma zasadniczo bardziej eleganckie modele repozytoriów. Subversion nigdy nie sprawi, że scalanie będzie działać, ponieważ model gałęzi directory == uniemożliwia prawdziwy postęp. Firmy takie jak David mogą coraz bardziej wypłukiwać szminkę na świni, ale svn nieuchronnie pozostanie w tyle za stanem techniki.
gtd,
7

Git sprawia, że ​​rozgałęzianie i scalanie jest naprawdę łatwe. Subversion 1.5 właśnie dodało śledzenie korespondencji seryjnej, ale Git jest jeszcze lepszy. Dzięki Git rozgałęzienie jest bardzo szybkie i tanie. Ułatwia to utworzenie gałęzi dla każdej nowej funkcji. Repozytoria Oh i Git są bardzo wydajne dzięki przestrzeni dyskowej w porównaniu do Subversion.

ejunker
źródło
6

Chodzi o łatwość użycia / kroki wymagane do zrobienia czegoś.

Jeśli tworzę pojedynczy projekt na komputerze / laptopie, git jest lepszy, ponieważ jest o wiele łatwiejszy w konfiguracji i użyciu. Nie potrzebujesz serwera i nie musisz ciągle wpisywać adresów URL repozytorium podczas scalania.

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

Gdy jednak wyjdziesz poza to, wybrałbym subwersję, ponieważ w tym momencie musisz skonfigurować „dedykowany” serwer lub lokalizację.

Możesz to zrobić równie dobrze z git, jak z SVN, ale korzyści z git przeważają nad koniecznością wykonania dodatkowych kroków w celu synchronizacji z serwerem centralnym. W SVN po prostu zatwierdzasz. W git musisz git commit, a następnie git push. Dodatkowy krok staje się irytujący po prostu dlatego, że tak często to robisz.

SVN ma również zaletę lepszych narzędzi GUI, jednak ekosystem git wydaje się szybko nadrabiać zaległości, więc nie martwię się o to w dłuższej perspektywie.

Orion Edwards
źródło
11
Oddzielenie zobowiązania od publikowania w Git jest zaletą IMHO, a nie wadą.
Jakub Narębski
Ok, więc jak oceniłbyś „łatwość użycia / kroki wymagane do zrobienia czegoś” dla SVN, gdy: - tworzenie gałęzi tematu do eksperymentów - łączenie tej gałęzi z inną gałęzią - dzielenie edytowanych elementów w pliku na ich własne mniejsze zatwierdzenia - szybkie sprawdzenie głównej gałęzi, aby zrobić małą poprawkę IMHO Nie widzę, jak skonfigurowanie serwera SVN jest łatwiejsze niż skonfigurowanie serwera git. I dlaczego chcesz zrezygnować ze wszystkich zalet, jakie daje lekka gałąź, żebyś nie musiał „naciskać osobno”.
Sam
Argument „gałąź tematu do eksperymentowania” jest często przedstawiany na korzyść gita, ale szczerze mówiąc, nigdy nie widziałem, żeby ktokolwiek robił to w subversion lub innym systemie innym niż DVCS. Być może to wielka sprawa i wszyscy tęsknimy, ale z tego, co widziałem, 99% programistów (w tym mnie) nie przejmuje się tematami, ponieważ nigdy ich nie używają! - Nie możesz przegapić tego, czego nigdy nie miałeś :-). Myślę, że jeśli ludzie DVCS zamierzają przedstawić „gałęzie tematyczne” jako funkcję, najpierw muszą przekonać wszystkich, że takie rzeczy są rzeczywiście przydatne.
Orion Edwards,
„Dzielenie edytowanego materiału na mniejsze zatwierdzenia” znów brzmi przyjemnie w teorii. Ale w ciągu ostatnich 3 lat ani razu nie pomyślałem „och, chciałbym to zrobić” i staram się nawet wymyślić hipotetyczną sytuację, w której mógłbym chcieć tej funkcji… Dużo gówna / Zwolennicy DVCS mówią po prostu: „mamy X, a X jest niesamowity” i wszyscy siedzą tam, zastanawiając się, dlaczego, u licha, kiedykolwiek potrzebowaliby X
Orion Edwards
6

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

Pat Notz
źródło
5

Ogólnie, Git i DVCS są świetne dla programistów wykonujących wiele kodowań niezależnie od siebie, ponieważ każdy ma swoją gałąź. Jeśli jednak potrzebujesz zmiany od kogoś innego, musi ona zobowiązać się do lokalnego repozytorium, a następnie musi przekazać ci ten zestaw zmian lub musisz go od siebie wyciągnąć.

Moje własne rozumowanie każe mi również myśleć, że DVCS utrudnia kontrolę jakości i zarządzanie wydaniami, jeśli robisz takie rzeczy, jak scentralizowane wydania. Ktoś musi być odpowiedzialny za wykonanie tego push / pull z repozytorium wszystkich innych, rozwiązywanie wszelkich konfliktów, które byłyby rozwiązane przy początkowym czasie zatwierdzania, następnie wykonanie kompilacji, a następnie umożliwienie wszystkim innym programistom ponownej synchronizacji repozytoriów.

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

jaredg
źródło
1
W rzeczywistości, jeśli wyglądasz, jak zarządzany jest sam jądro Linuksa lub sam projekt git, zobaczysz, że Git jest bardzo dobry dla przepływu pracy „jednego opiekuna” (lub opiekuna + poruczników), z jednym centralnym repozytorium. Ułatwia to tymczasowe przejście na kogoś innego jako opiekuna.
Jakub Narębski
5

Podoba mi się Git, ponieważ w rzeczywistości pomaga programistom komunikować się z programistami w średnich i dużych zespołach. Jako rozproszony system kontroli wersji, poprzez system push / pull, pomaga programistom w tworzeniu ekosystemu kodu źródłowego, który pomaga zarządzać dużą pulą programistów pracujących nad jednym projektem.

Na przykład powiedz, że ufasz 5 programistom i wyciągasz kody tylko z ich repozytorium. Każdy z tych programistów ma własną sieć zaufania, z której pobierają kody. Zatem rozwój opiera się na strukturze zaufania programistów, w której odpowiedzialność za kod jest dzielona przez społeczność programistów.

Oczywiście istnieją inne korzyści wymienione w innych odpowiedziach tutaj.

Mozammel
źródło
4

Nawiązało się do nich kilka odpowiedzi, ale chcę wyraźnie podkreślić 2 punkty:

1) Możliwość dokonywania wybiórczych zatwierdzeń (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 dokonanie zatwierdzenia, które zawiera tylko część zmian. Z Subversion jest to trudne.

2) Zdolność do dokonywania zmian bez podawania zmiany do wiadomości publicznej. W Subversion każde zatwierdzenie jest natychmiast publiczne, a zatem nieodwołalne. To znacznie ogranicza zdolność programisty do „wczesnego popełnienia, częstego popełnienia”.

Git to coś więcej niż tylko VCS; jest to również narzędzie do tworzenia poprawek. Subversion to tylko VCS.

William Pursell
źródło
4
Re 1) Jeśli używasz TortoiseSVN, AnkhSVN itp., To bardzo łatwo (trywialnie) wybrać, które pliki ze zmianami zatwierdzić. Re 2) Jeśli nie chcesz, aby inni deweloperzy otrzymali Twój kod, utwórz gałąź, a następnie połącz, gdy będzie gotowy, nie jest to trudne.
si618,
nieodwołalny? Cóż, możesz odwrócić scalanie błędnego zatwierdzenia, a repozytorium jest takie, jak było wcześniej. Ale masz rację, jest to udokumentowane. Ale czy to dobrze czy źle? Myślę, że to zależy ...
schoetbi,
@schoetbi Nie, szef repozytorium jest taki, jak był wcześniej. Samo repozytorium zawiera teraz dwa zatwierdzenia, ale byłoby miło, gdyby żadnego z nich nie było. To dodatkowy bałagan, który spowalnia cię, gdy przeglądasz kłody. Oczywiście może się to zdarzyć również w przypadku git, szczególnie jeśli niektórzy programiści mają zwyczaj pchania natychmiast po zatwierdzeniu. Ale git jest o wiele łatwiejszy do uniknięcia.
MatrixFrog,
4

Myślę, że Subversion jest w porządku .. dopóki nie zaczniesz scalać .. lub robić cokolwiek skomplikowanego .. lub robić cokolwiek, co Subversion uważa za skomplikowane (jak robienie zapytań, aby dowiedzieć się, które gałęzie pomieszały z danym plikiem, skąd faktycznie pochodzi zmiana , wykrywanie kopii i wklejania itp.) ...

Nie zgadzam się z zwycięską odpowiedzią, mówiąc, że główną korzyścią GIT jest praca offline - z pewnością jest przydatna, ale jest bardziej dodatkowa w moim przypadku użycia. SVK może również pracować offline, wciąż nie mam pytania, w które z nich zainwestować mój czas nauki).

Po prostu jest niesamowicie mocny i szybki, a przyzwyczajony do pojęć - bardzo przydatny (tak, w tym sensie: przyjazny dla użytkownika).

Aby uzyskać więcej informacji na temat łączącej się historii, zobacz: Używanie git-svn (lub podobnego) * tylko *, aby pomóc w scaleniu svn?

inger
źródło
3

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

dbr
źródło
3

Absolutnie uwielbiam móc zarządzać lokalnymi gałęziami mojego kodu źródłowego w Git bez zamulania wody w centralnym repozytorium. W wielu przypadkach wyewidencjonuję kod z serwera Subversion i uruchomię lokalne repozytorium Git, aby móc to zrobić. Wspaniale jest również, że inicjowanie repozytorium Git nie zanieczyszcza systemu plików wieloma irytującymi folderami .svn wszędzie.

A jeśli chodzi o obsługę narzędzi Windows, TortoiseGit bardzo dobrze radzi sobie z podstawami, ale nadal wolę wiersz poleceń, chyba że chcę wyświetlić dziennik. Naprawdę podoba mi się sposób, w jaki Tortoise {Git | SVN} pomaga podczas czytania dzienników zatwierdzania.

Matt Hulse
źródło
3

To niewłaściwe pytanie. Zbyt łatwo jest skupić się na brodawkach gita i sformułować argument, dlaczego subwersja jest rzekomo lepsza, przynajmniej w niektórych przypadkach użycia. Fakt, że git został pierwotnie zaprojektowany jako zestaw konstrukcyjny kontroli wersji niskiego poziomu i ma barokowy interfejs zorientowany na programistę Linux, ułatwia świętym wojnom zdobycie trakcji i postrzeganie zasadności. Zwolennicy Git walą w bęben milionami zalet przepływu pracy, które svn faceci uważają za niepotrzebne. Wkrótce cała debata została sformułowana jako scentralizowana vs rozproszona, co służy interesom społeczności narzędziowej svn dla przedsiębiorstw. Firmy, które zwykle publikują najbardziej przekonujące artykuły o przewadze subwersji w przedsiębiorstwie,

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

Podczas gdy możesz wziąć git i zbudować scentralizowaną zamianę subversion dość łatwo, mimo że svn istnieje ponad dwa razy dłużej, nigdy nie był w stanie uzyskać nawet podstawowego śledzenia scalania działającego w pobliżu tak dobrze, jak w git. Jednym z podstawowych powodów jest decyzja projektowa, aby gałęzie były takie same jak katalogi. Nie wiem, dlaczego pierwotnie wybrali się w ten sposób, co z pewnością sprawia, że ​​częściowe kasy są bardzo proste. Niestety uniemożliwia również prawidłowe śledzenie historii. Teraz oczywiście powinieneś stosować konwencje układu repozytorium subversion, aby oddzielić gałęzie od zwykłych katalogów, a svn używa pewnych heurystyk, aby wszystko działało w codziennych przypadkach użycia. Ale wszystko to po prostu pomija bardzo kiepską i ograniczającą decyzję projektową na niskim poziomie. Możliwość różnicowania pod względem repozytorium (zamiast różnic pod względem katalogów) jest podstawową i krytyczną funkcją systemu kontroli wersji i znacznie upraszcza elementy wewnętrzne, umożliwiając tworzenie inteligentniejszych i przydatnych funkcji na nim. Widać, ile wysiłku włożono w rozszerzenie subwersji, a jednak jak daleko jest ona do obecnej uprawy nowoczesnych VCS pod względem podstawowych operacji, takich jak rozwiązywanie scalania.

Oto moja radosna i agnostyczna rada dla każdego, kto wciąż uważa, że ​​Subversion jest wystarczająco dobry na dającą się przewidzieć przyszłość:

Subversion nigdy nie dogoni nowszych ras VCS, które nauczyły się na błędach RCS i CVS; jest to technicznie niemożliwe, chyba że od podstaw zmienią model repozytorium, ale wtedy tak naprawdę nie byłoby svn, prawda? Niezależnie od tego, jak bardzo uważasz, że nie posiadasz możliwości współczesnego VCS, twoja ignorancja nie ochroni cię przed pułapkami Subversion, z których wiele to sytuacje niemożliwe lub łatwe do rozwiązania w innych systemach.

Niezwykle rzadko zdarza się, że techniczna niższość rozwiązania jest tak wyraźna, jak w przypadku svn, na pewno nigdy nie wypowiedziałbym takiej opinii na temat wygranej z linuksem lub emacsa przeciwko vs, ale w tym przypadku jest tak clearcut i kontrola źródła są tak podstawowym narzędziem w arsenale programisty, że uważam, że należy to jednoznacznie stwierdzić. Niezależnie od wymogu używania svn z powodów organizacyjnych, błagam wszystkich użytkowników svn, aby ich logiczny umysł nie skonstruował fałszywego przekonania, że ​​bardziej nowoczesne VCS są użyteczne tylko w przypadku dużych projektów typu open source. Bez względu na charakter pracy programistycznej, jeśli jesteś programistą, będziesz bardziej skutecznym programistą, jeśli nauczysz się korzystać z lepiej zaprojektowanych VCSes, czy to Git, Mercurial, Darcs, czy wielu innych.

gtd
źródło
2

Subversion jest bardzo łatwe w użyciu. W ciągu ostatnich lat nigdy nie znalazłem 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 Git otrzymujesz bardziej elastyczny VCS. Możesz używać go w taki sam sposób jak SVN ze zdalnym repozytorium, w którym zatwierdzasz wszystkie zmiany. Możesz jednak używać go głównie w trybie offline i od czasu do czasu przesuwać zmiany do zdalnego repozytorium. Ale Git jest bardziej złożony i ma bardziej stromą krzywą uczenia się. Po raz pierwszy znalazłem się w niewłaściwych gałęziach, tworząc gałęzie pośrednio lub otrzymując komunikaty o błędach z niewielką ilością informacji o pomyłce i gdzie muszę szukać w Google, aby uzyskać lepsze informacje. Niektóre proste rzeczy, takie jak podstawianie znaczników ($ Id $) nie działa, ale GIT ma bardzo elastyczny mechanizm filtrowania i przechwytywania do łączenia własnych skryptów, dzięki czemu dostajesz wszystko, czego potrzebujesz i więcej, ale potrzebuje więcej czasu i czytania dokumentacji ;)

Jeśli pracujesz głównie w trybie offline z lokalnym repozytorium, nie masz kopii zapasowej, jeśli coś zostanie utracone na komputerze lokalnym. W SVN pracujesz głównie ze zdalnym repozytorium, które jest jednocześnie tym samym, co tworzenie kopii zapasowych 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 Linux i potrzebach rozproszonego systemu kontroli wersji.

Czy Git jest lepszy od SVN? Programiści, którzy potrzebują tylko historii wersji i mechanizmu tworzenia kopii zapasowych, mają dobre i łatwe życie dzięki SVN. Programiści często pracujący z oddziałami, testujący więcej wersji jednocześnie lub pracujący głównie offline mogą korzystać z funkcji Git. Istnieje kilka bardzo przydatnych funkcji, takich jak ukrywanie ukrytych plików SVN, które mogą ułatwić życie. Ale z drugiej strony nie wszyscy ludzie będą potrzebować wszystkich funkcji. Więc nie widzę zmarłych SVN.

Git potrzebuje lepszej dokumentacji, a raportowanie błędów 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 z Eclipse działa, ale nie została oficjalnie wydana i nie ma oficjalnej strony aktualizacji (tylko niektóre zewnętrzne witryny aktualizacji z okresowymi kompilacjami z bagażnika http://www.jgit.org/updates ) Tak więc najbardziej preferowany sposób korzystania z Git w tych dniach to linia poleceń.

devarni
źródło
2

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

Peter Mortensen
źródło
2

Dla osób szukających dobrego Git GUI, Syntevo SmartGit może być dobrym rozwiązaniem. Jego zastrzeżony, ale darmowy do użytku niekomercyjnego, działa na Windows / Mac / Linux, a nawet obsługuje SVN przy użyciu pewnego rodzaju mostka git-svn, tak myślę.

jotik
źródło
1

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

Myślę, że dość bezpiecznie jest powiedzieć, że wśród programistów SVN vs. Od pewnego czasu szaleje argument Git, a każdy ma własne zdanie na temat tego, co jest lepsze. Zostało to nawet poruszone w pytaniach podczas naszego seminarium internetowego na temat Subversion w 2010 roku i później.

Hyrum Wright, nasz dyrektor Open Source i prezes Subversion Corporation, mówi o różnicach między Subversion a Git, a także innymi rozproszonymi systemami kontroli wersji (DVCS).

Mówi także o nadchodzących zmianach w Subversion, takich jak Working Copy Next Generation (WC-NG), które jego zdaniem spowodują powrót wielu użytkowników Gita do Subversion.

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

użytkownik270537
źródło
Oczywiście stronniczy, ponieważ jego narzędzie opiera się na Subversion. Tylko mówię.
Jakub Narębski
1

Mieszkam ostatnio na ziemi Git i podoba mi się to w projektach osobistych, ale nie byłbym w stanie zmienić projektów na Subversion z uwagi na zmianę sposobu myślenia pracowników, bez żadnych naglących korzyści. Co więcej, największy projekt, który realizujemy we własnym zakresie, jest niezwykle zależny od svn: zewnętrznych, które z tego, co do tej pory widziałem, nie działają tak dobrze i bezproblemowo w Git.

Peter Mortensen
źródło
1

Po pierwsze, jednoczesna kontrola wersji wydaje się łatwym problemem do rozwiązania. Wcale nie jest. Tak czy siak...

SVN jest dość nieintuicyjny. Git jest jeszcze gorszy. [sarkastyczna spekulacja] Może to być spowodowane tym, że programiści, którzy lubią trudne problemy, takie jak równoczesna kontrola wersji, nie są zainteresowani 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, kiedy używamy wyłącznie Gita, jestem wierzący. Teraz kontrola wersji działa dla mnie ORAZ zespołu / projektu zamiast po prostu pracować dla projektu. Kiedy potrzebuję oddziału, rozgałęziam się. Czasami jest to gałąź, która ma odpowiednią gałąź na serwerze, a czasami nie. Nie wspominając już o wszystkich innych zaletach, nad którymi będę musiał się uczyć (częściowo dzięki tajemnemu i absurdalnemu brakowi interfejsu użytkownika, który jest nowoczesnym systemem kontroli wersji).

Yar
źródło