Dlaczego Git lepszy niż Subversion?

głosy
393

Używam Subversion przez kilka lat, a po użyciu SourceSafe , ja po prostu kocham Subversion. W połączeniu z TortoiseSVN , nie mogę sobie wyobrazić jak to mogło być lepiej.

Jednak istnieje coraz większa liczba deweloperów twierdząc, że Subversion ma problemy i że powinno być przejście do nowej rasy rozproszonych systemów kontroli wersji, takich jak Git .

W jaki sposób poprawić Git na Subversion?

Utwórz 03/08/2008 o 23:38
źródło użytkownik
W innych językach...                            


30 odpowiedzi

głosy
548

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

Kluczową różnicą jest to, że jest zdecentralizowany. Wyobraź sobie, że jesteś programistą na drodze, można rozwijać na swoim laptopie i chcesz mieć kontrolę źródłowego, dzięki czemu można wrócić 3 godziny.

Z Subversion, masz problem: SVN Repository może znajdować się w miejscu, które nie może dotrzeć (w firmie, a nie masz internet w tej chwili), nie można popełnić. Jeśli chcesz zrobić kopię kodu, trzeba dosłownie kopiuj / wklej go.

Z Git, nie mają tego problemu. Twoja lokalna kopia jest repozytorium, można zobowiązać się do niego i uzyskać wszystkie korzyści z kontroli źródła. Po odzyskaniu połączenia do głównego repozytorium, można popełnić przeciwko niemu.

To wygląda dobrze na początku, ale po prostu pamiętać dodatkową złożoność tego podejścia.

Git wydaje się być „nowe, błyszczące, cool” rzeczy. To nie oznacza złe (nie ma powodu Linus napisał ją dla rozwoju Linux Kernel po wszystkich), ale czuję, że wielu ludzi skok na „Rozproszone źródła sterowania” pociąg właśnie dlatego, że jest nowy i został napisany przez Linusa Torvaldsa, bez faktycznego wiedząc dlaczego / czy to lepiej.

Subversion ma problemy, ale tak nie Git, Mercurial CV TFS czy cokolwiek innego.

Edit: Więc ta odpowiedź jest teraz rok i nadal generuje wiele upvotes, więc pomyślałem, dodam jeszcze kilka wyjaśnień. W ostatnim roku od pisania tego, Git zyskał dużo dynamiki i wsparcie, zwłaszcza od strony takie jak GitHub naprawdę wystartował. Używam zarówno Git i Subversion dzisiaj i chciałbym podzielić się osobistą wiedzę.

Przede wszystkim, Git może być bardzo mylące na początku, kiedy zdecentralizowana roboczych. Czym jest zdalne? i Jak prawidłowo skonfigurować początkowe repozytorium? Są dwa pytania, które pojawią się na początku, zwłaszcza w porównaniu do SVN proste „svnadmin create”, Git jest „git init” może wziąć parametry --bare i --shared który wydaje się być „właściwy” sposób skonfigurować scentralizowany magazyn. Istnieją powody do tego, ale to zwiększa złożoność. Dokumentacja polecenia „Zamówienie” jest bardzo mylące dla osób zmieniających się - „właściwego” sposób wydaje się być „clone git”, podczas gdy „git checkout” wydaje się przełączyć oddziałów.

Git naprawdę błyszczy, jeśli są zdecentralizowane. Mam serwer w domu i laptop na drodze, i SVN po prostu nie działa dobrze tutaj. Z SVN, nie mogę mieć kontrolę źródła lokalnego, jeśli nie jestem podłączony do repozytorium (Tak, wiem o SVK lub o sposoby, aby skopiować repo). Z Git, to tryb domyślny i tak. Jest to dodatkowa komenda chociaż (git commit zobowiązuje lokalnie, natomiast git mistrz pochodzenie Push pcha oddział główny do zdalnego o nazwie „pochodzenie”).

Jak wspomniano powyżej: Git dodaje złożoności. Dwa tryby tworzenia repozytoriów, kasie kontra klon popełnić vs. naciśnięciem ... Musisz wiedzieć, które nakazuje pracę lokalnie i które pracują z „serwera” (jestem zakładając, większość ludzi wciąż jakby centralnym repozytorium „master-” ).

Ponadto, oprzyrządowanie jest wciąż niewystarczająca, przynajmniej na Windows. Tak, tam jest Visual Studio AddIn, ale nadal używać git bash z msysGit.

SVN ma tę zaletę, że jest dużo prostsze do nauki: Jest repozytorium, wszystkie zmiany w tym kierunku, jeśli wiesz, jak tworzyć, popełnić i kasa i jesteś gotowa do pracy i może pickup rzeczy jak rozgałęzienia, zaktualizuj itp później na.

Git ma tę zaletę, że jest znacznie lepiej nadaje się, jeśli niektórzy deweloperzy nie są zawsze połączone z głównym repozytorium. Ponadto, jest to o wiele szybciej niż SVN. A z tego co słyszę, rozgałęzienia i łączenie wsparcia jest dużo lepiej (co należy się spodziewać, gdyż są to podstawowe powody było napisane).

To również wyjaśnia, dlaczego zyskuje tyle brzęczenie w Internecie, jak Git doskonale nadaje się dla projektów Open Source Wystarczy Widelec Opisz swoje zmiany na swój widelec, a następnie poprosić Opiekun projektu pociągnąć zmiany. Z Git, to po prostu działa. Naprawdę, spróbuj go na Github, to magia.

Co widzę też są git-svn Mosty: Centralne repozytorium Subversion jest repo, ale deweloperzy lokalnie pracy z Git i most następnie wypycha ich zmian w SVN.

Ale nawet z tego długiego Ponadto, nadal podtrzymuję moją rdzenia wiadomości: Git nie jest lepsze lub gorsze, to jest po prostu inna. Jeśli masz potrzebę „Offline Kontroli źródło” i chęć spędzenia trochę czasu uczenia się, to fantastyczne. Ale jeśli masz ściśle scentralizowanej kontroli źródła i / lub walczą o wprowadzenie regulacji źródła w pierwszej kolejności, ponieważ twoi współpracownicy nie są zainteresowani, to prostota i doskonałe oprzyrządowanie (przynajmniej na Windows) z SVN połysk.

Odpowiedział 03/08/2008 o 23:45
źródło użytkownik

głosy
145

Z Git, można zrobić praktycznie nic nieaktywny, ponieważ każdy ma swoje własne repozytorium.

Dokonywanie gałęzie i scalanie między oddziałami jest naprawdę łatwe.

Nawet jeśli nie masz popełnić prawa do projektu, nadal można mieć własne repozytorium online, a wnioski publikuje „push” dla swoich poprawek. Każdy, kto lubi swoje poprawki może pociągnąć ich do swojego projektu, w tym oficjalnych opiekunów.

To trywialne do talerza projektu, modyfikować je i nadal zachować połączenia w poprawek z gałęzi głową.

Git działa dla programistów jądra Linux. Oznacza to, że jest bardzo szybki (ma być), a waga do tysięcy użytkowników. GIT wykorzystuje również mniej miejsca (do 30 razy mniej miejsca na składowiska Mozilla).

Git jest bardzo elastyczny, bardzo TIMTOWTDI (Jest więcej niż jeden sposób, aby to zrobić). Można używać workflow cokolwiek chcesz, i Git będzie go wspierać.

Wreszcie, nie GitHub , wspaniałym miejscu na organizację swoich repozytoriów Git.

Wady Git:

  • jest to o wiele trudniejsze do opanowania, ponieważ Git ma więcej pomysłów i więcej poleceń.
  • Korekty nie mają numerów wersji jak w Subversion
  • Wiele poleceń Git są tajemnicze i komunikaty o błędach są bardzo nieprzyjazny dla użytkownika
  • brakuje mu dobrego GUI (takich jak wielkiej TortoiseSVN )
Odpowiedział 04/08/2008 o 01:24
źródło użytkownik

głosy
110

Inne odpowiedzi zrobili dobrą robotę wyjaśniając podstawowe funkcje Git (które są super). Ale jest też tak wiele małych sposobów, że Git zachowuje się lepiej i pomaga utrzymać moje życie bardziej rozsądny. Oto niektóre z małych rzeczy:

  1. Git ma polecenie „czyste”. SVN rozpaczliwie potrzebuje tego polecenia, biorąc pod uwagę jak często będzie zrzucić dodatkowe pliki na dysku.
  2. Git ma polecenie „przepoławiać”. To miłe.
  3. SVN tworzy katalogi .svn w każdym folderze (GIT tworzy tylko jeden katalog .git). Każdy skrypt piszesz, a co grep zrobisz, będą musiały zostać napisane na ignorowanie tych katalogów .svn. Musisz również całą komendę ( „wywóz svn”) po to, żeby sane kopię swoich plików.
  4. W SVN, każdy plik i folder może pochodzić z innej zmiany lub oddziału. Początkowo brzmi to miło mieć tę swobodę. Ale co to właściwie znaczy, że tam jest milion różnych sposobów dla lokalnej kasie być całkowicie spieprzył. (Na przykład, jeśli „svn przełącznik” nie w połowie, lub jeśli wprowadzisz błędne polecenie). A najgorsze jest to: jeśli kiedykolwiek dostać się do sytuacji, w której niektóre z plików pochodzi z jednego miejsca, a niektóre z nich z innego, „status svn” powie, że wszystko jest normalne. Musisz zrobić „svn info” na każdego pliku / katalogu, aby dowiedzieć się, jak dziwne rzeczy. Jeśli „stan git” mówi, że rzeczy są normalne, to można zaufać, że rzeczy naprawdę są normalne.
  5. Trzeba powiedzieć SVN ilekroć je przenieść lub usunąć coś. Git po prostu zrozumieć.
  6. Ignoruj semantyka są łatwiejsze w Git. Jeśli zignorujesz wzoru (takie jak * .pyc), zostanie ona zignorowana dla wszystkich podkatalogów. (Ale jeśli naprawdę chcesz, aby zignorować coś dla tylko jednego katalogu, można). Z SVN, wydaje się, że nie istnieje prosty sposób zignorować wzór we wszystkich podkatalogów.
  7. Kolejna pozycja z udziałem ignorować plików. Git sprawia, że ​​możliwe są „prywatne” ignorować ustawienia (przy użyciu pliku .git / info / wyłączyć), które nie wpłyną na nikogo innego.
Odpowiedział 26/09/2008 o 01:18
źródło użytkownik

głosy
56

Dlaczego Git jest lepszy niż X ” przedstawia różne zalety i wady Git vs innych projektów SCM.

Krótko:

  • Git śledzi zawartość zamiast plików
  • Gałęzie są lekkie i scalanie jest łatwy , a mam na myśli naprawdę proste .
  • Jest rozprowadzane w zasadzie każdy repozytorium jest gałęzią. Jest o wiele łatwiej rozwijać równolegle i wspólnie niż z Subversion, moim zdaniem. To również sprawia, nieaktywny możliwości rozwoju.
  • To nie nakłada żadnych obieg , jak widać na powyższym połączonej stronie , istnieje wiele możliwych przepływów pracy z Git. Subversion stylu workflow jest łatwo naśladować.
  • Git repozytoria są znacznie mniejsze rozmiary plików niż repozytoriów Subversion. Jest tylko jedno „.git” katalog, w przeciwieństwie do dziesiątek „.svn” repozytoriów (nota Subversion 1.7 i wyżej teraz używa pojedynczego katalogu jak Git).
  • Inscenizacja obszar jest niesamowite, że pozwala zobaczyć zmiany można dokonać, popełnić częściowych zmian i robić różne inne rzeczy.
  • Stashing jest nieoceniona, gdy robisz „chaotyczny” rozwoju, lub po prostu chcesz naprawić błąd, gdy jesteś nadal pracuje na coś innego (na innym oddziale).
  • Można przepisać historię , która doskonale nadaje się do przygotowywania zestawów połączeniowych i ustalenie swoje błędy ( zanim opublikujesz te rewizje)
  • ... i wiele więcej.

Istnieją pewne wady:

  • Nie ma jeszcze wiele dobrych GUI dla niego. Jest nowy i Subversion zostało około dużo dłużej, więc to naturalne, jak istnieje kilka interfejsów w rozwoju. Niektóre z nich to dobre TortoiseGit i GitHub for Mac .
  • Częściowe kasach / klonami repozytoria nie są możliwe w danej chwili (czytałem, że jest to w rozwoju). Jednak nie jest modułem wsparcie. Git 1.7+ obsługuje rozrzedzone kas .
  • To może być trudniejsze do opanowania, choć nie uważam, że jest to przypadek (około rok temu). Git niedawno poprawił swój interfejs i jest bardzo łatwy w obsłudze.

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

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

i

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Gdzie Git naprawdę błyszczy jest rozgałęzienia i pracy z innymi ludźmi.

Odpowiedział 10/02/2009 o 05:18
źródło użytkownik

głosy
54

Google Tech Talk: Linus Torvalds na git

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

Strona porównanie GIT jest Wiki

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

Odpowiedział 03/08/2008 o 23:44
źródło użytkownik

głosy
26

Cóż, to jest rozłożone. Benchmarki pokazują, że jest to znacznie szybciej (biorąc pod uwagę jego charakter rozproszony, operacje takie jak dyferencjału i dzienniki są wszystkie lokalne więc oczywiście to niesamowicie szybciej w tym przypadku), a katalogi robocze są mniejsze (które nadal wieje zdanie).

Podczas pracy na Subversion, lub jakiegokolwiek innego systemu kontroli wersji klient / serwer, to zasadniczo tworzyć kopie na komputerze działa poprzez sprawdzanie-out wersjami. Stanowi migawkę w czasie co repozytorium wygląda. Zaktualizować swoją kopię roboczą poprzez aktualizacje i zaktualizować repozytorium poprzez zobowiązuje.

Z rozproszonej kontroli wersji, nie masz migawkę, ale raczej cały codebase. Chce zrobić diff z 3 miesięcy starej wersji? Nie ma problemu, wersja 3 miesiąca życia jest nadal na swoim komputerze. To oznacza nie tylko rzeczy są sposób szybszy, ale jeśli jesteś odłączony od centralnego serwera, nadal można zrobić wiele operacji masz w zwyczaju. Innymi słowy, nie wystarczy mieć migawkę danej zmiany, ale cały codebase.

Można by pomyśleć, że Git zajęłoby sporo miejsca na dysku twardym, ale od kilku benchmarkach widziałem, to faktycznie zajmuje mniej. Nie pytaj mnie, jak to zrobić. To znaczy, że został zbudowany przez Linusa, wie to i owo o systemach plików Chyba.

Odpowiedział 03/08/2008 o 23:47
źródło użytkownik

głosy
22

Główne punkty lubię DVCS są te:

  1. Można popełnić połamane rzeczy. To nie ma znaczenia, ponieważ inni ludzie nie będą widzieć ich aż opublikujesz. Czas publikacji jest różny od popełnienia czasu.
  2. Z tego powodu można popełnić częściej.
  3. można scalić pełną functionnality. Ten functionnality będzie mieć swój własny oddział. Wszystkie rewizje tej branży będą związane z tym functionnality. Można to zrobić z CVC jednak z DVCS swoją domyślną.
  4. Można przeszukiwać historię (znaleźć, gdy funkcja zmieniona)
  5. Możesz cofnąć ciągnąć jeśli ktoś spieprzył głównego repozytorium, nie trzeba, aby naprawić błędy. Wystarczy wyczyścić seryjnej.
  6. Kiedy trzeba kontrolę źródłowy w dowolnym katalogu zrobić: git init,. i można popełnić, cofanie zmian, itp ...
  7. Jest szybki (nawet w systemie Windows)

Głównym powodem, dla stosunkowo dużego projektu jest poprawa komunikacji stworzony przez punkt 3. Inne są ładne premie.

Odpowiedział 04/09/2008 o 12:06
źródło użytkownik

głosy
15

Najśmieszniejsze jest to: I gospodarzem projektów w Subversion Repos, ale dostęp do nich za pomocą polecenia git clone.

Proszę przeczytać Develop z Git na Google Code Project

Chociaż Google Code natywnie mówi Subversion, można łatwo używać Git podczas rozwoju. Szukając „git svn” sugeruje, praktyka ta jest powszechna, a my zachęcamy do eksperymentowania z nim.

Korzystanie Git na repozytorium SVN daje mi korzyści:

  1. Mogę pracować rozłożone na kilku maszynach, zatwierdzanie i wyciągając z nich oraz
  2. Mam centralne backup/public repozytorium SVN dla innych, aby sprawdzić
  3. I są one swobodnie korzystać Git na własną rękę
Odpowiedział 02/10/2008 o 14:05
źródło użytkownik

głosy
11

Wszystkie odpowiedzi są tu zgodnie z oczekiwaniami, programista centric, jednak co się stanie, jeśli firma korzysta kontroli poprawek poza kodem źródłowym? Istnieje wiele dokumentów, które nie są w kod źródłowy, które korzystają z kontrolą wersji, i powinien żyć blisko kodzie, a nie w innym CMS. Większość programistów nie działają w izolacji - pracujemy dla firm w ramach zespołu.

Mając to na uwadze, porównaj łatwość obsługi, zarówno w oprzyrządowanie klienta i szkoleń, między Subversion i git. Nie widzę scenariusz, w którym każdy Rozproszony system kontroli wersji będzie łatwiejszy w użyciu lub wyjaśnić nie-programista. Chciałbym być w błędzie, bo wtedy będę w stanie ocenić git i rzeczywiście nadzieja to akceptowane przez ludzi, którzy potrzebują kontroli wersji, które nie są programiści.

Nawet wtedy, jeśli poproszony przez kierownictwo dlaczego powinniśmy przejść od scentralizowanego do rozproszonego systemu kontroli wersji, będę ciężko dać uczciwą odpowiedź, ponieważ nie jest to potrzebne.

Zastrzeżenie: Zainteresowałem się Subversion wcześnie (około v0.29), więc oczywiście jestem stronniczy, ale firmy Pracowałem dla Od tego czasu korzystają z mojego entuzjazmu, bo już zachęcać i wspierać jego wykorzystanie. I podejrzewam, że jest to, jak to się dzieje w przypadku większości producentów oprogramowania. Przy tak wielu programistów skoki za modą git, zastanawiam się, jak wiele firm zamierza przegapić korzyści wynikające z zastosowania kontroli wersji kodu źródłowego na zewnątrz? Nawet jeśli mają oddzielne systemy dla różnych zespołów, jesteś brakuje obecnie na niektóre z korzyści, takich jak (Unified) integracji emisyjnej śledzenia, podczas gdy rosnące wymagania konserwacji sprzętu i szkoleń.

Odpowiedział 13/10/2009 o 08:01
źródło użytkownik

głosy
9

Subversion jest nadal znacznie bardziej przyzwyczajeni system kontroli wersji, co oznacza, że ma lepszą obsługę narzędzia. Znajdziesz dojrzałych wtyczek SVN dla prawie każdego IDE , i są dobre rozszerzenia explorer dostępne (jak TurtoiseSVN). Poza tym, muszę zgodzić się z Michaelem : Git nie jest lepszy lub gorszy niż Subversion, jest inaczej.

Odpowiedział 18/09/2008 o 19:44
źródło użytkownik

głosy
8

David Richards WANdisco Blog o Subversion / GIT

Pojawienie GIT przyniósł ze sobą rasy fundamentalistów dvcs - The „Gitterons” - to, że coś innego niż GIT jest bzdura. W Gitterons wydaje się, inżynieria oprogramowania dzieje się na własnej wyspie i często zapominają, że większość organizacji nie zatrudnia wyłącznie starszych inżynierów oprogramowania. To jest ok, ale to nie jest jak reszta rynku myśli, i jestem szczęśliwy, aby to udowodnić: GIT, w ostatniej wygląd 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ły rynek.

Problem widzieliśmy było to, że Gitterons strzelali (tanie) strzałów na Subversion. Tweety jak „Subversion jest więc [powolny / brzydko / restrykcyjne / nie pachnie / 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 lat stara / I wygrał sześciokrotnie działa na stole blackjacka]. Dostajesz obraz.

Odpowiedział 17/09/2010 o 19:22
źródło użytkownik

głosy
8

Jedną z rzeczy, która mnie irytuje Subversion jest to, że stawia własny folder w każdym katalogu projektu, natomiast git stawia tylko jeden w katalogu głównym. To nie jest to nic wielkiego, ale takie małe rzeczy, które sumują się.

Oczywiście, Subversion Tortoise, który jest [zwykle] bardzo miłe.

Odpowiedział 22/08/2008 o 16:24
źródło użytkownik

głosy
7

Git sprawia także rozgałęzienia i scalanie naprawdę łatwe. Subversion 1.5 tylko dodał śledzenia scalania, ale Git jest jeszcze lepiej. Z GIT rozgałęzienia jest bardzo szybki i tani. To sprawia, że ​​utworzenie oddziału dla każdej nowej funkcji bardziej realne. No i repozytoriów Git są bardzo wydajne z miejsca w porównaniu do Subversion.

Odpowiedział 09/08/2008 o 04:22
źródło użytkownik

głosy
6

Łatwy Git ma ładny strony porównując rzeczywiste wykorzystanie Git i SVN , która daje wyobrażenie o tym, co może zrobić rzeczy Git (lub zrobić łatwiej) w porównaniu do SVN. (Technicznie, to opiera się na łatwym Git, która jest lekka owijka na szczycie Git).

Odpowiedział 22/08/2008 o 16:19
źródło użytkownik

głosy
6

Chodzi o łatwość użytkowania / kroków wymaganych do zrobienia czegoś.

Jeśli Zajmuję jeden projekt na komputerze PC / laptop, Git jest lepszy, ponieważ jest znacznie łatwiejsze w konfiguracji i użyciu. Nie trzeba serwer, a nie trzeba zachować wpisując adres URL repozytorium, kiedy robisz scala.

Gdyby to było tylko 2 osoby, powiedziałbym git jest łatwiejsze, ponieważ można po prostu wcisnąć i wyciągnąć od siebie.

Gdy pojawi się poza tym jednak, że pójdę za wywrotową, ponieważ w tym momencie trzeba założyć „” serwer dedykowany lub lokalizację.

Można to równie dobrze jak z git zrobić z SVN, ale korzyści z git uzyskać przeważają koniecznością zrobienia dodatkowych kroków w celu synchronizacji z serwerem centralnym. W SVN po prostu popełnić. W git trzeba git commit, następnie git push. Dodatkowym krokiem staje się irytujące po prostu dlatego, że kończy się to robić tak dużo.

SVN ma również korzyści z lepszych narzędzi graficznych, jednak ekosystem git wydaje się być szybko nadrabiają zaległości, więc nie martw się o to w dłuższej perspektywie.

Odpowiedział 04/08/2008 o 00:38
źródło użytkownik

głosy
5

Lubię Git, ponieważ faktycznie ułatwia komunikację wywoływacz do wywoływacza na nośniku do dużego zespołu. Jako rozproszonego systemu kontroli wersji, za pośrednictwem systemu Push / pull pomaga deweloperom tworzyć kod źródłowy eko-system, który pomaga zarządzać dużą pulę programistów pracujących nad jednym projektem.

Na przykład powiedzieć ufasz 5 deweloperów i tylko wyciągnąć kodów z ich repozytorium. Każdy z tych twórców ma własną sieć zaufania, z którego one ciągnąć kody. Zatem rozwój opiera się na tej tkaninie zaufania deweloperów gdzie odpowiedzialność kodu udostępnionego wśród społeczności programistów.

Oczywiście istnieją inne korzyści, które są wymienione tutaj w innych odpowiedzi.

Odpowiedział 05/10/2008 o 17:52
źródło użytkownik

głosy
5

Git i DVCS w ogóle jest wielki dla programistów robić dużo kodowania niezależnie od siebie, bo każdy ma swój własny oddział. Jeśli potrzebujesz zmiany od kogoś innego, choć ona musi zobowiązać się do swojego lokalnego repo a potem musi pchać ten changeset do ciebie albo trzeba wyciągnąć go z niej.

Moje własne rozumowanie również sprawia mi myśleć DVCS sprawia, że ​​rzeczy trudniejsze do kontroli jakości i zarządzania zwolnić jeśli robisz takie rzeczy jak scentralizowanych wydaniach. Ktoś musi być odpowiedzialny za to, że Push / pull z każdego innego repozytorium, rozwiązywania konfliktów, które zostały rozwiązane w początkowej przed popełnić czas, a następnie robi kompilacji, a następnie posiadające wszystkie inni deweloperzy Ponowna synchronizacja ich operacje repo.

Wszystko to można rozwiązać za pomocą procesów ludzkich, oczywiście; DVCS prostu złamał coś który został ustalony przez scentralizowaną kontrolą wersji, aby zapewnić nowe udogodnienia.

Odpowiedział 04/08/2008 o 00:08
źródło użytkownik

głosy
4

Myślę Subversion jest w porządku .. aż zaczniesz łączenie .. lub cokolwiek skomplikowany .. lub cokolwiek Subversion myśli jest skomplikowana (jak robi zapytań aby dowiedzieć się, który rozgałęzia grzebał danego pliku, jeżeli zmiana faktycznie pochodzi, wykrywającym Kopiuj i past itp) ...

Nie zgadzam się z wygranej odpowiedź, mówiąc, że główną korzyścią z GIT jest offline praca - to z pewnością przydatne, ale to nic więcej jak dodatkowy dla mojego przypadku użycia. SVK może pracować w trybie offline też, nadal nie ma dla mnie pytanie, który z nich zainwestować swój czas nauki w).

Tyle, że jest to niezwykle silny i szybki, a także -po przyzwyczaić do koncepcji - bardzo użyteczne (tak, w tym sensie: przyjazny dla użytkownika).

Więcej informacji na temat historii łączenie, zobacz: Korzystanie z git-svn (lub podobny) * tylko * wydźwignąć z seryjnej svn?

Odpowiedział 27/07/2010 o 16:40
źródło użytkownik

głosy
4

Kilka odpowiedzi nie nawiązywał do nich, ale chcę mieć 2 punkty wyraźne:

1) zdolność do selektywnego przesyła potwierdzenie (na przykład git add --patch). Jeśli katalog roboczy zawiera wiele zmian, które nie są częścią tej samej zmiany logiczne, Git sprawia, że bardzo łatwo zrobić commit, który obejmuje tylko część zmian. Z Subversion, jest to trudne.

2) zdolność do popełnienia bez dokonywania zmian społeczeństwu. W Subversion, każdy popełnić natychmiast publicznej, a tym samym nieodwołalna. To znacznie ogranicza zdolność autora do „popełnienia wcześnie popełnienia często”.

Git jest więcej niż tylko VCS; jest to również narzędzie do tworzenia łat. Subversion jest jedynie VCS.

Odpowiedział 07/08/2009 o 15:59
źródło użytkownik

głosy
3

To jest źle postawione pytanie należy pytać. To wszystko jest zbyt proste, by skupić się na brodawki git i sformułować tezę o tym, dlaczego Subversion jest rzekomo lepsze, przynajmniej dla niektórych przypadków użycia. Fakt, że git został pierwotnie zaprojektowany jako niskiego poziomu kontroli wersji zestawu budowlanego i ma barokowy linux-developer-zorientowany interfejs ułatwia święte wojny zyskać trakcję i postrzeganej legitymacji. Git zwolennicy huk bębna z milionami zalet przepływu pracy, które SVN faceci głosić niepotrzebne. Wkrótce cała debata jest sformułowane jako scentralizowana vs rozpowszechniane, który służy interesom społeczności instrument Przedsiębiorstwo svn. Te firmy, które zazwyczaj zgasić najbardziej przekonujących artykuły o wyższości Subversion w przedsiębiorstwie,

Ale tutaj jest problem: Subversion jest architektoniczny dead-end .

Natomiast można wziąć git i budować scentralizowany wymiany subversion dość łatwo, mimo że od ponad dwukrotnie dłuższy svn nigdy nie była w stanie uzyskać nawet podstawowe seryjnej śledzenia pracę wszędzie blisko, jak to ma miejsce w git. Jeden podstawowy powód tego jest decyzja projektowa, aby oddziały takie same jak katalogi. Nie wiem, dlaczego poszli w ten sposób pierwotnie, to na pewno sprawia, że ​​częściowe kas bardzo proste. Niestety to również uniemożliwia właściwie śledzić historię. Teraz oczywiście ci mają używać Subversion konwencje repozytorium oddzielić od regularnych oddziałów katalogów i svn wykorzystuje pewne heurystyki, aby wszystko działa dla codziennych zastosowań. Ale to wszystko jest tylko tapetowanie na bardzo słabe i ograniczenia decyzji projektowych niskopoziomowe. Będąc w stanie zrób repozytorium mądry diff (zamiast katalogu mądry różnice) to podstawowe i kluczowe znaczenie dla funkcjonalności systemu kontroli wersji, a także znacznie upraszcza wewnętrzne, dzięki czemu możliwe jest budowanie inteligentnych i użytecznych funkcji na wierzchu. Można zobaczyć w ilości wysiłku, który został oddany do rozciągającej się dywersji, a jeszcze jak daleko jest od obecnych upraw nowoczesnych VCSes w zakresie podstawowych operacji, takich jak rozdzielczość seryjnej.

Teraz tutaj jest moje serce, filc i agnostyk rada dla każdego, kto nadal wierzy Subversion jest wystarczająco dobre w najbliższej przyszłości:

Subversion nigdy nie dogonić nowszych ras VCSes że nauczyli się na błędach RCS i CVS; jest to niemożliwe, chyba że retool techniczne modelu repozytorium od podstaw, ale to nie byłoby naprawdę svn to? Niezależnie od tego, ile uważasz, że nie możliwości nowoczesnego VCS, twoja niewiedza nie chroni przed pułapkami Subversion, z których wiele jest sytuacji, które są niemożliwe lub łatwo rozwiązane w innych systemach.

Jest to niezwykle rzadkie, że niższości techniczne rozwiązania jest tak jednoznaczne, jak to jest z SVN, z pewnością nigdy stwierdzić taką opinię o win-vs-linux lub emacs-vs-vi, ale w tym przypadku to jest tak clearcut i źródło sterowania jest takie podstawowe narzędzie w arsenale programisty, że czuję należy stwierdzić jednoznacznie. Niezależnie od wymogu stosowania svn względów organizacyjnych, błagam wszystkie svn użytkownikom, aby nie pozwolić ich logiczny umysł skonstruować fałszywe przekonanie, że bardziej nowoczesne VCSes są użyteczne tylko dla dużych projektów open-source. Bez względu na charakter swojej pracy rozwojowej, jeśli jesteś programistą, będzie bardziej skuteczna, jeśli programista nauczyć się wykorzystywać lepiej zaprojektowanych VCSes, czy to Git, Mercurial, Darcs, lub wiele innych.

Odpowiedział 29/05/2011 o 18:30
źródło użytkownik

głosy
3

I absolutnie uwielbiam być w stanie zarządzać lokalnych oddziałów mojego kodu źródłowego w Git bez zaciemniania się wodę z centralnego repozytorium. W wielu przypadkach będę kasy kod z serwera Subversion i uruchomienie lokalnego repozytorium git, tylko żeby być w stanie to zrobić. Jest to także wielki, że inicjowanie repozytorium Git nie zanieczyszcza plików z gronem irytujących foldery .svn wszędzie.

A jeśli chodzi o wsparcie narzędzi Windows TortoiseGit uchwyty podstawy bardzo dobrze, ale nadal preferują wiersz polecenia, chyba że chcę, aby wyświetlić dziennik. Bardzo podoba mi się sposób, Tortoise {Git | SVN} pomaga podczas czytania popełnić logów.

Odpowiedział 10/02/2010 o 23:54
źródło użytkownik

głosy
3

Dzięki temu, że nie musi komunikować się z centralnym serwerem stale, prawie każdy biegnie dowodzenia w mniej niż sekundę (oczywiście git pchania / ciągnięcia / sprowadzić są wolniejsze po prostu dlatego, że mają do initalise połączenia SSH). Rozgałęzienie jest daleko, daleko łatwiej (jedna prosta komenda do oddziału, jedna prosta komenda scalić)

Odpowiedział 30/08/2008 o 13:01
źródło użytkownik

głosy
2

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

Odpowiedział 09/03/2011 o 15:05
źródło użytkownik

głosy
2

Eric Sink od SourceGear napisał serię artykułów na temat różnic między rozproszonych systemów sterowania i nondistributed wersja. Porównuje on plusy i minusy z najpopularniejszych systemów kontroli wersji. Bardzo ciekawa lektura.
Artykuły można znaleźć na jego blogu, www.ericsink.com :

Odpowiedział 13/10/2009 o 14:36
źródło użytkownik

głosy
2

Subversion jest bardzo łatwy w użyciu. Nigdy nie znalazłem się w ostatnich latach problem lub, że coś nie działa zgodnie z oczekiwaniami. Ponadto istnieje wiele doskonałych narzędzi GUI i wsparcie dla integracji SVN jest duża.

Z Git uzyskać bardziej elastyczne VCS. Można go używać w taki sam sposób jak SVN ze zdalnym repozytorium, gdzie popełnił wszystkie zmiany. Ale można też używać go głównie w trybie offline i tylko popchnąć zmiany od czasu do czasu do zdalnego repozytorium. Ale Git jest bardziej złożona i ma bardziej stromą krzywą uczenia się. Znalazłem się po raz pierwszy podjęciem niewłaściwych oddziałów, tworząc oddziały pośrednio lub otrzymać komunikaty o błędach nie było zbyt wiele informacji o pomyłkę i gdzie muszę szukać z Google, aby uzyskać lepsze informacje. Kilka prostych rzeczy, jak podstawienie markerów ($ id $) nie działa, ale GIT ma bardzo elastyczny mechanizm filtrowania i hak do łączenia własnych skryptów i tak masz 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ś jest tracona na lokalnym komputerze. Z SVN jesteś głównie pracy ze zdalnym repozytorium, który jest również w tym samym czasie kopii zapasowej na innym serwerze ... Git może działać w ten sam sposób, ale to nie było głównym celem Linus mieć coś podobnego SVN2. Został on zaprojektowany dla programistów jądra Linux oraz potrzeb rozproszonego systemu kontroli wersji.

Git jest lepszy niż SVN? Deweloperzy, który potrzebuje tylko trochę historii wersji i mechanizm tworzenia kopii zapasowych mają dobre i łatwe życie z SVN. Deweloperzy często pracujących z oddziałów, testowanie kolejne wersje w tym samym czasie lub pracujących głównie w trybie offline można korzystać z funkcji Git. Istnieje kilka bardzo przydatnych funkcji, takich jak stashing Nie znaleziono z SVN, które mogą uczynić życie łatwiejszym. Ale z drugiej strony nie wszyscy ludzie będą musieli wszystkie funkcje. Więc nie widzę martwych z SVN.

Git potrzebuje lepszej dokumentacji i raportowanie błędów musi być bardziej pomocny. Również istniejące użyteczne GUI są rzadko. Tym razem znalazłem tylko 1 GUI dla Linuksa ze wsparciem większości funkcji Git (git-cola). Eclipse integracja działa, ale to nie jest oficjalny wydany i nie ma oficjalna aktualizacja (tylko część zewnętrzna strona aktualizacja z periodyku buduje od tułowia http://www.jgit.org/updates ), więc najkorzystniejszym sposobem użycia Git ten dzień jest linia poleceń.

Odpowiedział 13/10/2009 o 14:14
źródło użytkownik

głosy
1

Dlatego myślę, że jest lepszy niż Subversion Git (przynajmniej dla projektów pracuję dalej), głównie ze względu na jego użyteczność i prostszą workflow:

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

Odpowiedział 22/10/2010 o 17:25
źródło użytkownik

głosy
1

I zostały mieszkania w Git ziemi ostatnio, a ja lubię je dla osobistych projektów, ale nie będzie w stanie przełączać projekty pracy z nim jeszcze z Subversion z uwagi na zmiany w myśleniu o wymaganych od personelu, bez żadnych naglących korzyści. Ponadto największy projekt prowadzimy w domu jest bardzo zależna od svn: zewnętrznymi , które z tego co widziałem do tej pory, nie pracują tak ładnie i płynnie w Git.

Odpowiedział 25/04/2010 o 22:35
źródło użytkownik

głosy
1

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

Myślę, że to dość bezpiecznie powiedzieć, że wśród deweloperów, SVN VS. Git Argument został szaleje już od jakiegoś czasu, a każdy mający swój własny pogląd na temat, który jest lepszy. Zostało to nawet wychowany w pytań podczas naszej Webinar na Subversion w 2010 roku i później.

Hyrum Wright, nasz dyrektor Open Source i prezydenta dla Subversion Corporation opowiada o różnicach między Subversion i Git, wraz z innymi rozproszonych systemów sterowania wersji (DVCS).

Opowiada też o nadchodzących zmianach w Subversion, takich jak praca kopiowania Next Generation (WC-NG), która jego zdaniem spowoduje liczbę użytkowników Git przekonwertować z powrotem do Subversion.

Mieć zegarek swojego filmu i daj nam znać, co myślisz albo przez komentowania na tym blogu, lub zamieszczając na naszych forach. Rejestracja jest prosta i zajmie tylko chwilę!

Odpowiedział 10/02/2010 o 19:51
źródło użytkownik

głosy
1

Git w Windows jest dość dobrze obsługiwane teraz.

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

oraz instrukcja dla lepszego doświadczenia Okna Git.

Odpowiedział 10/02/2010 o 17:29
źródło użytkownik

głosy
1

Po pierwsze, równoczesna kontrola wersja wydaje się łatwy do rozwiązania problemem. To nie jest w ogóle. Tak czy inaczej...

SVN jest dość nieintuicyjne. Git jest jeszcze gorzej. [Sarkastyczny-spekulacje] Może to być, ponieważ deweloperzy, że jak twarde problemów, takich jak równoczesnej kontroli wersji, nie mają większego zainteresowania w tworzeniu dobrego UI. [/ Sarkastyczny-spekulacje]

SVN zwolennicy uważają, że nie potrzebują rozproszonego systemu kontroli wersji,. Pomyślałem, że też. Ale teraz, że używamy wyłącznie Git, jestem wierzący. Teraz kontrola wersja działa dla mnie i zespołu / projektu, a nie tylko pracować dla projektu. Kiedy potrzebny jest oddział, I Oddziału. Czasami jest to oddział, który ma odpowiedni oddział na serwerze, a czasami nie. Nie wspominając o wszystkich innych zalet, że będę musiał iść uczyć się na (po części dzięki tej tajemnej i absurdalnego braku interfejsu użytkownika, który jest nowoczesny system kontroli wersji).

Odpowiedział 03/01/2010 o 13:45
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more