Czy powinienem używać SVN lub Git? [Zamknięte]

Rozpoczynam nowy projekt rozproszony. Czy powinienem używać SVN lub Git i dlaczego?

SVN to jedno repo i wielu klientów. Git to repozytorium z dużą ilością repozytoriów klientów, z których każda ma użytkownika. Jest zdecentralizowany do tego stopnia, że ​​ludzie mogą śledzić lokalne zmiany bez konieczności wypychania rzeczy na zewnętrzny serwer.

SVN został zaprojektowany tak, aby był bardziej centralny, gdzie Git opiera się na tym, że każdy użytkownik ma swoje własne repozytorium Git, a te repozytorium wypychają zmiany z powrotem do centralnego. Z tego powodu Git zapewnia użytkownikom lepszą lokalną kontrolę wersji.

Tymczasem masz wybór między TortoiseGit , GitExtensions (a jeśli hostujesz swoje „centralne” repozytorium git na github, ich własny klient - GitHub dla Windows ).

Jeśli chcesz wydostać się z SVN, możesz trochę ocenić Bazaar . Jest to jeden z systemów kontroli wersji nowej generacji, które mają ten rozproszony element. Nie jest zależny od POSIX jak git, więc istnieją natywne kompilacje Windows i ma kilka potężnych marek open source.

Ale może nawet nie potrzebujesz jeszcze tego rodzaju funkcji. Zobacz funkcje, zalety i wady rozproszonych VCS . Jeśli potrzebujesz więcej niż ofert SVN, rozważ jedną. Jeśli tego nie zrobisz, możesz chcieć trzymać się doskonałej integracji SVN (obecnie) z pulpitem.

Nigdy nie rozumiem tej koncepcji „git nie jest dobry w systemie Windows”; Tworzę wyłącznie pod Windows i nigdy nie miałem żadnych problemów z git.

Zdecydowanie poleciłbym git zamiast subwersji; jest po prostu o wiele bardziej wszechstronny i umożliwia „rozwój offline” w sposób, który nigdy tak naprawdę nie byłby możliwy. Jest dostępny na prawie każdej możliwej platformie i ma więcej funkcji, niż prawdopodobnie będziesz kiedykolwiek używać.

Oto kopia odpowiedzi na moje zduplikowane pytanie, które od tamtej pory usunąłem na temat Git vs. SVN (wrzesień 2009).

Lepszy? Oprócz zwykłego linku WhyGitIsBetterThanX różnią się one:

jeden to Centralny VCS oparty na taniej kopii dla oddziałów i tagów drugi (Git) to rozproszony VCS oparty na wykresie poprawek. Zobacz także Podstawowe koncepcje VCS .

Ta pierwsza część wygenerowała kilka błędnych uwag, udając, że podstawowy cel obu programów (SVN i Git) jest taki sam, ale zostały one wdrożone zupełnie inaczej.
Aby wyjaśnić podstawową różnicę między SVN a Git , pozwól mi sformułować:

• SVN to trzecia implementacja kontroli wersji : RCS, następnie CVS i wreszcie SVN zarządzają katalogami wersjonowanych danych. SVN oferuje funkcje VCS (etykietowanie i scalanie), ale jego znacznik jest tylko kopią katalogu (jak gałąź, z tym wyjątkiem, że nie należy „dotykać” niczego w katalogu znaczników), a jego scalanie jest nadal skomplikowane, obecnie oparte na meta -dodano dane, aby zapamiętać to, co już zostało scalone.

• Git to narzędzie do zarządzania zawartością plików (narzędzie służące do scalania plików), które przekształciło się w prawdziwy system kontroli wersji , oparty na DAG ( Directed Acyclic Graph ) zatwierdzeń, w których gałęzie są częścią historii danych (a nie samych danych) ) i gdzie tagi są prawdziwymi metadanymi.

Stwierdzenie, że nie różnią się „zasadniczo”, ponieważ można osiągnąć to samo, rozwiązać ten sam problem, jest… po prostu fałszywe na wielu poziomach.

• jeśli masz wiele złożonych scaleń, wykonywanie ich przy użyciu SVN będzie dłuższe i bardziej podatne na błędy. jeśli musisz utworzyć wiele oddziałów, będziesz musiał nimi zarządzać i łączyć je, również znacznie łatwiejsze w Git niż w SVN, zwłaszcza jeśli w grę wchodzi duża liczba plików (wtedy prędkość staje się ważna)
• jeśli masz częściowe scalenia dla trwającej pracy, skorzystasz z obszaru przejściowego Git (indeks), aby zatwierdzić tylko to, czego potrzebujesz, ukryć resztę i przejść do innej gałęzi.
• jeśli potrzebujesz programowania offline ... cóż, dzięki Git jesteś zawsze „online”, z własnym lokalnym repozytorium, niezależnie od tego, jaki przepływ pracy chcesz wykonać z innymi repozytoriami.

Wciąż jednak komentarze do tej starej (usuniętej) odpowiedzi nalegały:

VonC: Mylicie podstawową różnicę we wdrażaniu (różnice są bardzo fundamentalne, oboje wyraźnie się z tym zgadzamy) z różnym celem.
Oba narzędzia są używane do tego samego celu: dlatego wiele zespołów, które wcześniej korzystały z SVN, z powodzeniem zrzuciło go na korzyść Gita.
Gdyby nie rozwiązali tego samego problemu, ta substytucyjność nie istniałaby.

, na które odpowiedziałem:

„zastępowalność”… interesujący termin ( stosowany w programowaniu komputerowym ).
Oczywiście Git nie jest podtypem SVN.

Możesz uzyskać te same funkcje techniczne (tag, rozgałęzienie, scalanie) z obydwoma, ale Git nie przeszkadza i pozwala skupić się na zawartości plików , bez myślenia o samym narzędziu.

Z pewnością nie możesz (zawsze) po prostu zastąpić SVN przez Git „bez zmiany jakichkolwiek pożądanych właściwości tego programu (poprawność, wykonane zadanie, ...)” (co jest odniesieniem do wyżej wymienionej definicji zastępowalności ):

• Jedno jest rozszerzonym narzędziem do rewizji, drugie prawdziwym systemem kontroli wersji.
• Jeden jest odpowiedni dla małych i średnich projektów monolitycznych z prostym przepływem pracy scalania i (niezbyt dużą) wersjami równoległymi. SVN wystarczy do tego celu i możesz nie potrzebować wszystkich funkcji Git.
• Drugi pozwala na projekty od średnich do dużych oparte na wielu komponentach ( jedno repo na komponent ), z dużą liczbą plików do scalenia między wieloma gałęziami w złożonym przepływie pracy scalania, równoległe wersje w gałęziach, scalanie modernizacji i tak dalej. Możesz to zrobić za pomocą SVN, ale Git znacznie lepiej.
  SVN po prostu nie może zarządzać żadnym projektem o dowolnym rozmiarze za pomocą przepływu pracy scalania. Git może.

Ponownie ich natura jest zasadniczo inna (co następnie prowadzi do różnych wdrożeń, ale nie o to chodzi).
Jeden widzi kontrolę wersji jako katalogi i pliki, drugi widzi tylko zawartość pliku (tak bardzo, że puste katalogi nawet się nie zarejestrują w Git!).

Ogólny cel końcowy może być taki sam, ale nie można ich używać w taki sam sposób, ani nie można rozwiązać tej samej klasy problemu (pod względem zakresu lub złożoności).

2 kluczowe zalety SVN, które są rzadko cytowane:

1. Obsługa dużych plików. Oprócz kodu używam SVN do zarządzania moim katalogiem domowym. SVN jest jedynym VCS (rozproszonym lub nie), który nie dusi moich plików TrueCrypt (popraw mnie, jeśli istnieje inny VCS, który skutecznie obsługuje pliki 500 MB +). Jest tak, ponieważ porównania różnic są przesyłane strumieniowo (jest to bardzo istotny punkt). Rsync jest niedopuszczalny, ponieważ nie jest dwukierunkowy.

2. Kasa / rejestracja częściowego repozytorium (podkatalogu). Mercurial i bzr nie obsługują tego, a wsparcie gita jest ograniczone. Jest to złe w środowisku zespołowym, ale bezcenne, jeśli chcę sprawdzić coś na innym komputerze z mojego domowego reż.

Tylko moje doświadczenia.

Po przeprowadzeniu dalszych badań i przejrzeniu tego linku: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Niektóre wyciągi poniżej):

• Jest niesamowicie szybki. Żaden inny SCM, którego użyłem, nie był w stanie go nadążyć, a ja dużo z niego korzystałem, w tym Subversion, Perforce, darcs, BitKeeper, ClearCase i CVS.
• Jest w pełni rozpowszechniony. Właściciel repozytorium nie może dyktować sposobu mojej pracy. Mogę tworzyć oddziały i zatwierdzać zmiany bez połączenia z laptopem, a następnie synchronizować je z dowolną liczbą innych repozytoriów.
• Synchronizacja może odbywać się na wielu mediach. Kanał SSH, przez HTTP przez WebDAV, przez FTP lub wysyłając e-maile zawierające łatki do zastosowania przez odbiorcę wiadomości. Centralne repozytorium nie jest konieczne, ale można z niego korzystać.
• Oddziały są nawet tańsze niż w Subversion. Utworzenie gałęzi jest tak proste, jak zapisanie 41-bajtowego pliku na dysku. Usunięcie gałęzi jest tak proste, jak usunięcie tego pliku.
• W przeciwieństwie do gałęzi Subversion, mają swoją pełną historię. bez konieczności wykonywania dziwnej kopii i przeglądania kopii. Podczas korzystania z Subversion zawsze uważałem za niewygodne przeglądanie historii pliku na gałęzi, który pojawił się przed utworzeniem gałęzi. from #git: spearce: Nie rozumiem jednej rzeczy na temat SVN na stronie. Zrobiłem gałąź w SVN i przeglądanie historii pokazało całą historię jako plik w gałęzi
• Łączenie oddziałów jest prostsze i bardziej automatyczne w Git. W Subversion musisz pamiętać, z której ostatniej wersji połączyłeś się, aby móc wygenerować prawidłowe polecenie scalania. Git robi to automatycznie i zawsze robi to dobrze. Co oznacza, że ​​istnieje mniejsze prawdopodobieństwo popełnienia błędu podczas łączenia dwóch gałęzi.
• Scalanie oddziałów jest rejestrowane jako część właściwej historii repozytorium. Jeśli scalę dwie gałęzie razem lub jeśli scalę gałąź z powrotem do pnia, z którego pochodzi, ta operacja scalania zostanie zapisana jako część historii repozytorium jako wykonana przeze mnie i kiedy. Trudno zaprzeczyć, kto dokonał scalenia, gdy jest tam w dzienniku.
• Tworzenie repozytorium jest banalną operacją: mkdir foo; cd foo; git init To wszystko. Co oznacza, że ​​obecnie tworzę repozytorium Git. Zwykle używam jednego repozytorium na klasę. Większość tych repozytoriów ma mniej niż 1 MB miejsca na dysku, ponieważ przechowują tylko notatki z wykładów, zadania domowe i moje odpowiedzi LaTeX.
• Wewnętrzne formaty plików repozytorium są niezwykle proste. Oznacza to, że naprawa jest bardzo łatwa do wykonania, ale jeszcze lepsza, ponieważ jest tak prosta, że ​​bardzo trudno ją zepsuć. Nie sądzę, żeby ktokolwiek kiedykolwiek miał uszkodzone repozytorium Git. Widziałem Subversion z uszkodzonym fsfs. I widziałem, jak Berkley DB sam się korumpuje zbyt wiele razy, aby zaufać mojemu kodowi w backdenddzie Subversion bdb.
• Format pliku Gita jest bardzo dobry w kompresji danych, mimo że jest to bardzo prosty format. Repozytorium CVS projektu Mozilla ma około 3 GB; ma około 12 GB w formacie fsfs Subversion. W Git jest to około 300 MB.

Po przeczytaniu tego wszystkiego jestem przekonany, że Git jest właściwą drogą (choć istnieje trochę krzywej uczenia się). Używałem Git i SVN również na platformach Windows.

Chciałbym usłyszeć, co inni mają do powiedzenia po przeczytaniu powyższego?

Założyłbym repozytorium Subversion. Robiąc to w ten sposób, indywidualni programiści mogą zdecydować, czy używać klientów Subversion, czy klientów Git (z git-svn). Korzystanie git-svnnie zapewnia wszystkich korzyści pełnego rozwiązania Git, ale daje indywidualnym programistom dużą kontrolę nad własnym przepływem pracy.

Wierzę, że minie stosunkowo niewiele czasu, zanim Git będzie działał równie dobrze w systemie Windows, jak w systemach Unix i Mac OS X (od momentu zapytania).

Subversion ma doskonałe narzędzia dla systemu Windows, takie jak integracja TortoiseSVN dla Eksploratora i AnkhSVN dla integracji Visual Studio.

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, z łatwością możesz korzystać z 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ć rozłożone na kilku maszynach, zatwierdzanie i wyciągając z nich oraz
2. Mam centralne backup/public repozytorium SVN do sprawdzenia przez innych
3. I mogą swobodnie korzystać z Git na własny użytek

Naprawdę nie odpowiadam na twoje pytanie, ale jeśli chcesz skorzystać z rozproszonej kontroli wersji - brzmi to tak jak Ty - i używasz Windowsa, myślę, że lepiej byłoby użyć Mercuriala niż Git, ponieważ Mercurial ma znacznie lepszą obsługę Windows. Mercurial ma również port Mac.

Jeśli Twój zespół jest już zaznajomiony z oprogramowaniem do kontroli wersji i źródeł, takim jak CVS lub SVN, to w przypadku prostego i małego projektu (takiego, jak twierdzisz), radzę trzymać się SVN. Bardzo dobrze czuję się z svn, ale w obecnym projekcie e-commerce, który robię na django, postanowiłem pracować na git (używam git w trybie svn, to znaczy ze scentralizowanym repozytorium, które popycham i ściągam od w celu współpracy z co najmniej jednym innym programistą). Drugi programista czuje się dobrze z SVN i chociaż doświadczenia innych mogą się różnić, oboje mamy naprawdę kiepski czas na git dla tego małego projektu. (Oboje jesteśmy hardkorowymi użytkownikami Linuksa, jeśli to w ogóle ma znaczenie.)

Twój przebieg może się oczywiście różnić.

Zdecydowanie svn, ponieważ Windows jest - w najlepszym razie - obywatelem drugiej kategorii w świecie git(patrz http://en.wikipedia.org/wiki/Git_(software)#Portability więcej informacji można ).

AKTUALIZACJA: Przepraszam za zepsuty link, ale zrezygnowałem z próby uzyskania SO do pracy z identyfikatorami URI zawierającymi nawiasy. [link naprawiony teraz. -ed]

Najważniejsze jest to, że Git jest rozproszonym VCS, a Subversion scentralizowanym. Rozproszone VCS są nieco trudniejsze do zrozumienia, ale mają wiele zalet. Jeśli nie potrzebujesz tych zalet, Subversion może być lepszym wyborem.

Kolejnym pytaniem jest obsługa narzędzi. Który VCS jest lepiej obsługiwany przez narzędzia, których planujesz używać?

EDYCJA: Trzy lata temu odpowiedziałem w ten sposób:

Git działa obecnie w systemie Windows tylko za pośrednictwem Cygwin lub MSYS . Subversion od początku obsługiwał system Windows. Ponieważ rozwiązania git dla systemu Windows mogą działać dla Ciebie, mogą występować problemy, ponieważ większość programistów Gita pracuje z Linuksem i od początku nie miała na myśli przenośności. W tej chwili wolę Subversion do programowania w systemie Windows. Za kilka lat może to nie mieć znaczenia.

Teraz świat trochę się zmienił. Git ma teraz dobrą implementację w systemie Windows. Chociaż nie testowałem gruntownie na Windowsie (ponieważ nie używam już tego systemu), jestem całkiem pewien, że wszystkie główne VCS (SVN, Git, Mercurial, Bazaar) mają teraz właściwą implementację Windows. Ta korzyść dla SVN zniknęła. Pozostałe punkty (scentralizowane vs. rozproszone i sprawdzanie obsługi narzędzi) pozostają ważne.

Wybrałbym SVN, ponieważ jest on szerzej rozpowszechniony i lepiej znany.

Myślę, że Git byłby lepszy dla użytkownika Linuksa.

Git nie jest jeszcze obsługiwany w systemie Windows. Jest zoptymalizowany dla systemów Posix. Jednak uruchomienie Cygwin lub MinGW pozwala uruchomić Git z powodzeniem.

Obecnie wolę Git niż SVN, ale przekroczenie progu zajmuje trochę czasu, jeśli pochodzisz z CVS, SVN land.

Prawdopodobnie wybrałbym Git, ponieważ uważam, że jest znacznie potężniejszy niż SVN. Dostępne są tanie usługi Code Hosting, które działają dla mnie świetnie - nie musisz wykonywać kopii zapasowych ani żadnych prac konserwacyjnych - GitHub jest najbardziej oczywistym kandydatem.

To powiedziawszy, nie wiem nic na temat integracji Visual Studio i różnych systemów SCM. Wyobrażam sobie, że integracja z SVN jest znacznie lepsza.

Używam SVN od dłuższego czasu, ale ilekroć korzystałem z Git, czułem, że Git jest o wiele potężny, lekki i chociaż wymaga trochę krzywej uczenia się, ale jest lepszy niż SVN.

Zauważyłem, że każdy projekt SVN w miarę wzrostu staje się projektem o bardzo dużych rozmiarach, chyba że zostanie wyeksportowany. Gdzie natomiast projekt GIT (wraz z danymi Git) ma bardzo małą wagę.

W SVN miałem do czynienia z programistami od początkującego do eksperta, a nowicjusze i pośrednicy wydają się wprowadzać konflikty plików, jeśli kopiują jeden folder z innego projektu SVN, aby go ponownie użyć. Podczas gdy myślę, że w Git po prostu kopiujesz folder i działa, ponieważ Git nie wprowadza folderów .git we wszystkich jego podfolderach (tak jak robi to SVN).

Po długim postępowaniu z SVN, w końcu myślę o przeniesieniu moich programistów i mnie do Git, ponieważ łatwo jest współpracować i łączyć pracę, a jedną wielką zaletą jest to, że zmiany w lokalnej kopii mogą zostać popełnione w takim samym stopniu pożądane, a następnie w końcu przekazane do oddziału na serwerze za jednym razem, w przeciwieństwie do SVN (gdzie musimy od czasu do czasu zatwierdzać zmiany w repozytorium na serwerze).

Ktoś, kto może mi pomóc zdecydować, czy naprawdę powinienem iść z Git?

Wszystko sprowadza się do:

Czy twój rozwój będzie liniowy? Jeśli tak, powinieneś trzymać się Subversion.

Z drugiej strony, twój rozwój nie będzie liniowy, co oznacza, że ​​będziesz musiał utworzyć rozgałęzienie dla różnych zmian, a następnie scalić takie zmiany z powrotem do głównej linii rozwojowej (znanej jako Git jako gałąź główna), a następnie Git zrobi to DUŻO więcej dla Ciebie.

czy próbowałeś Bzr ?

Jest całkiem niezły, Connonical (ludzie, którzy tworzą Ubuntu), stworzyli go, ponieważ nie lubili niczego innego na rynku ...

Czy mogę rozwinąć pytanie i zapytać, czy Git działa dobrze na MacOS?

Odpowiedz na komentarze: Dzięki za wiadomość, nie mogłem się doczekać, aby to wypróbować. Zainstaluję go w domu na komputerze Mac.

Jest na ten temat ciekawe wideo na YouTube. Jego autorem jest sam Linus Torwalds: Goolge Tech Talk: Linus Torvalds na git

SVN wydaje się dobrym wyborem pod Windows, jak wskazują inni ludzie.

Jeśli jakiś programista chce wypróbować GIT, zawsze może użyć GIT-SVN, w którym repozytorium SVN jest odtwarzane w repozytorium GIT. Następnie powinien być w stanie pracować lokalnie z GIT, a następnie użyć SVN do opublikowania jego zmian w głównym repozytorium.

Musisz iść z DVCS, to jest jak skok kwantowy w zarządzaniu źródłami. Osobiście używam Monotone a jego przyspieszony czas rozwoju nie ma końca. Używamy go w systemach Windows, Linux i Mac i jest bardzo stabilny. Mam nawet buildbota, który wykonuje nocne kompilacje projektu na każdej z platform.

DVCS podczas dystrybucji zwykle oznacza, że ​​utworzysz centralny serwer tylko dla ludzi, którzy będą wypychać zmiany do iz.