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

321

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

rudigrobler
źródło
5
Tak, git działa na Macu. Jeśli użyjesz Macports, aby go zainstalować, zainstaluje nawet interfejs Mac do interfejsów zatwierdzania i przeglądania.
Seth Johnson
3
@Andre - ponieważ możesz korzystać z MonoDevelop - przełączam się z Vault na SVN, dzięki czemu mogę tworzyć oprogramowanie .NET na moim komputerze Mac lub PC. Nie było klienta dla Vault, ale był dla SVN :-)
schmoopy,
4
Github / bitbucket + sourcetree = niebo! - sourcetreeapp.com
thecodeassassin

Odpowiedzi:

253

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.

Oli
źródło
24
Może także rzucić okiem na Hg (Mercury)
Joel
24
Od października 2008 roku sytuacja się poprawiła. Możesz zainstalować TortoiseGit, pobrać najnowszą przenośną wersję MSysGit i powiedzieć TortoiseGit, gdzie go znaleźć. Właśnie przeniosłem moje duże repozytorium svn na git, ponieważ słaba obsługa zmiany nazwy svn w końcu doprowadziła mnie do szału.
We Are All Monica,
4
Od 2 lat mamy teraz kilka dobrych narzędzi do okien. Obecnie używam netbeans z MSysGit. Miałem też szczęście z TortoiseGit. Myślę, że jest wystarczająco dobry, aby go użyć w produkcji. Biorąc pod uwagę, jak trudno jest zarządzać prostymi konfliktami w git subversion, jest to ogromna poprawa.
Keyo
24
Używamy Git w systemie Windows intensywnie i już od dłuższego czasu. Git jest absolutnie fantastyczny w systemie Windows.
Charlie Flowers,
13
@Oli Dobrze byłoby zaktualizować swoją odpowiedź (zwłaszcza o kliencie Windows Git) na podstawie komentarzy tutaj i doświadczenia. Obecna odpowiedź wydaje się tendencyjna, gdy minęły 2-3 lata od jej napisania.
amit
111

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

Dark Shikari
źródło
9
Z drugiej strony miałem pewne problemy z git na Windowsie, to naprawdę dziwne rzeczy dla mojego repo. I używałem najnowszej wersji w cygwin (to było coś jak miesiąc temu).
Roman Plášil
7
@Roman: cóż, port Cygwin nie jest prawie tym samym co natywny port win32. Spodziewam się, że port Cygwin jest znacznie gorzej przetestowany ...
SamB
49
„więcej funkcji, niż zapewne kiedykolwiek użyjesz” to czerwona flaga w mojej książce
BT
26
@ BT „czerwona flaga” Nie zgadzam się. Często żałuję, że nie ma sposobu, aby coś zrobić i po krótkich poszukiwaniach dowiaduję się, że jest kilka poleceń, o których nie wiedziałem, tylko to. Używam GIT również na moim komputerze z systemem Windows i nie mam jeszcze żadnych poważnych problemów.
testowanie123
@ test123123, ale wtedy nie są to funkcje „prawdopodobnie [n] kiedykolwiek użyjesz”, ponieważ w rzeczywistości z nich korzystałeś.
mulllhausen,
77

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

VonC
źródło
10
Nie zgadzam się z tobą, że git i svn są zasadniczo różne, ale nie zgadzam się co do wielu twoich punktów. svn mógł zostać napisany w celu zastąpienia cvs, ale w żaden inny sposób nie są one powiązane, podczas gdy cvs zaczynały się jako skrypty na RCS, więc istnieje bezpośredni związek. Mimo to osoba, którą podajesz, ma całkowitą rację, obie zasadniczo zarządzają wersjami plików, implementacją i procesem, w którym to się dzieje (lub jak to robi) są szczegółami implementacji. To jak różnica między CRC i SHA1, zasadniczo bardzo różne, ale robią to samo.
Erik Funkenbusch
37

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.

użytkownik154489
źródło
6
„Proszę mnie poprawić, jeśli istnieje inny system VCS, który skutecznie obsługuje pliki o pojemności ponad 500 MB” - Oczywiście, wymuś!
James Creasy
8
Perforce = non-free. Ponadto Perforce nie jest dostępny dla wszystkich platform.
WhyNotHugo
4
Dlaczego nie umieścić repozytorium SVN WEWNĄTRZ kontenerów truecrypt? Możesz także tunelować to przez ssh i skonfigurować serwer do przechowywania tego konkretnego repozytorium w innym pliku truecrypt. Ma to tę dodatkową zaletę, że można dokonywać częściowych transakcji tego repozytorium.
WhyNotHugo
1
@Hugo, o ile mi wiadomo, klient Perforce jest dostępny dla systemów Windows, Unix, Linux, Mac, Amiga, BeOS, Cygwin, HPUX, IBM AS / 400, OS / 2, DEC VMS i Novell File Server. Czy na liście brakuje odpowiedniej platformy?
eis
1
Tak, OpenBSD (i wiedziałem to z doświadczenia, nie musiałem google go). Myślę, że to też nie zadziała na Maemo, chociaż mogę się mylić (i tak, używam git na Maemo).
WhyNotHugo
25

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?

Waqar
źródło
15
Git jest niewiarygodnie szybki w niektórych operacjach, głównie dlatego, że operacja wpływa tylko na lokalne repozytorium. Na przykład, sprawdzanie Git nie powinno być słusznie porównywane z sprawdzaniem SVN, ponieważ sprawdzanie SVN jest również zmianą w repozytorium pomostowym dla reszty twojego zespołu. Że wymaga się hitem sieci, a porównując Git ma zobowiązać się do sieci przypomina formę transferu sieciowego nieodpowiednie porównania. Jeśli zgodzisz się, a następnie stracisz dysk twardy, w Git stracisz zmianę. To dobrze, jeśli tego oczekujesz, ale nie jest to oczekiwane w SCM nie dystrybuowanych.
Edwin Buck
1
@EdwinBuck Nie biorąc pod uwagę tego, co zrobił Waqar, w testach nawet przy uwzględnieniu czasu sieciowego git wydaje się być szybszy: git-scm.com/about/small-and-fast
Sqeaky
Twój punkt „Tworzenie repozytorium jest trywialną operacją” jest niezwykle ważny, szczególnie w systemie Windows: w porównaniu do SVN o wiele łatwiej jest szybko zasymulować kilka połączonych rozproszonych repozytoriów połączonych z centralnym repozytorium za pomocą Git niż robi to analogicznie do SVN (zainstaluj aplikację serwera SVN dla Windows itp.). Również (dziwnie) uważam, że Git jest bardziej spójny w różnych systemach operacyjnych: linia poleceń jest bardzo dobrze zaprojektowana, a zatem wystarczająca przez większość czasu (i praktycznie identyczna w różnych systemach operacyjnych) w porównaniu z różnymi natywnymi aplikacjami klient / serwer SVN ...
Shivan Dragon
1
Artykuł wiki, do którego się odwołujesz, jest pełen błędów. Dlatego twoja odpowiedź jest zła. Doceniony. Na stronie wiki znajduje się strona dyskusji, która odwołuje się do strony svnvsgit.com , wyjaśniając, dlaczego porównanie jest nieprawidłowe.
bahrep
Niezwykle szybki? Przeniosłem projekt Ciforth z lokalnego CVS do Github. Jest to prosty projekt, ale ma jeden duży główny plik źródłowy zawierający 10 000 wierszy. Jeśli spróbuję użyć winy w tym pliku, github upada. Przeważnie, jeśli ktoś nie zadowala się szybkim mówieniem i upiera się przy użyciu takiego kwalifikatora, nie jest to wyważona opinia, co powoduje, że jestem podejrzliwy w stosunku do wszystkiego, co mówisz. Groetjes Albert
Albert van der Horst
12

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.

Greg Hewgill
źródło
11

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
Andre Bossard
źródło
3
Tylko uwaga: od lipca 2011 r. Google Code obsługuje natywnie Git.
Jeremy Salwen
9

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.

Dave Webb
źródło
9

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

ayaz
źródło
8

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]

Hank Gay
źródło
1
FYI: umieść adres URL w nawiasach kątowych lub zamień nawiasy na% 28 i% 29.
PhiLho,
1
Czy kodowanie URL będzie działało dla składni [] ()?
Hank Gay
16
To jest niepoprawny FUD. Git jest fantastyczny w systemie Windows. A SVN jest wszędzie zły.
Charlie Flowers,
6
Wszystkim, którzy mnie głosują, proszę cofnąć się i spojrzeć na komentarze deweloperów z około 2008 roku: jest całkiem jasne, że Linus i gang nie dbali o obsługę systemu Windows. W porządku: ja też nie chcę tego robić, a moje oprogramowanie nie jest tak skomplikowane jak VCS, które oczekuje POSIXish od systemu plików. Jednak niesprawiedliwe jest scharakteryzowanie mojego stwierdzenia jako FUD, jeśli spojrzysz na kontekst.
Hank Gay
2
Być może w 2008 roku git był zły w systemie Windows, ale używam msysgit od 2009 roku i działa bezbłędnie. Obejmuje to gitk, offline odpowiednik GitHub na pulpicie.
Dan Dascalescu
8

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.

Memento
źródło
Jestem optymistą, że horyzont nieistotności będzie znacznie krótszy niż kilka lat.
Greg Hewgill
Tak, być może potrwa to tylko rok. Git ma dynamiczną społeczność programistów. Ale wywrotka też. Za rok lub dwa będziesz musiał ponownie spojrzeć na oba, aby odpowiedzieć na to pytanie.
Mnementh
1
Teraz jest rok lub dwa później. Jak to wygląda :)
Merlyn Morgan-Graham
3
Git nie ma rozszerzenia modelu rozproszonego SCM na inne fazy potoku tworzenia oprogramowania. Nie mamy dobrego modelu dla rozproszonych systemów kompilacji, rozproszonych testów automatycznych, kontroli jakości, kontroli wersji itp. Po prostu otrzymujemy eksperymentalne wsparcie dla rozproszonej kopii zapasowej, a to po dziesięcioleciach badań. W związku z tym Git oferuje więcej programistom, a mniej procesowi tworzenia oprogramowania. Wszystkie implementacje Git ostatecznie błogosławią jedno repozytorium jako centralne, co upraszcza najciekawsze zdolności Gita w faksymile SVN.
Edwin Buck
1
@hibbelig Git nie ma centralnego repozytorium, każde repozytorium jest efektywnie (ze względu na rozproszony projekt) równe. Oznacza to, że albo przerobisz rurociąg produkcyjny, aby ewentualnie obsługiwał wszystkie repozytoria w jednakowy sposób, albo sztucznie błogosławisz jedno repozytorium, które ma status „sztucznie podwyższonego poziomu” (inaczej repozytorium centralne ). Jeśli zrobisz to pierwsze, nikt nie wie dużo o budowaniu równoległych potoków, w których wydanie może pochodzić z dowolnego biurka programisty, jeśli zrobisz to drugie, obietnica rozproszonego przetwarzania jest oszukiwana przez scentralizowaną konwencję.
Edwin Buck
6

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

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

Burkhard
źródło
1
To się jednak szybko zmienia. SVN traci udział w rynku, a GIT zyskuje: Na przykład: wikivs.com/wiki/Git_vs_Subversion#Popularity lub programmers.stackexchange.com/questions/136079/…
Zelphir Kaltstahl
@Zelphir: Nie zadzwoniłbym szybko 7 lat, ale tak, GIT zdobywa udziały w rynku i jest szczególnie lepszy do łączenia plików.
Burkhard
4

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.


źródło
8
Zdefiniuj „natywnie”. msysgit działa dobrze
Milan Babuškov
4

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.

Christoph Schiessl
źródło
4

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?

Waqar
źródło
Nie zadzwoniłbym do żadnego programisty, który skopiowałby folder kontrolowany przez SVN do innego projektu, aby go ponownie używał i nie spodziewał się oczywistych problemów jako „pośrednich”. Nazwałbym ich nowicjuszami. Tak, masz rację, wynika to z podfolderu .svn, który informuje SVN do jakiego repozytorium należą pliki. Jeśli użytkownik usunie ten podfolder .svn, może zaimportować folder do nowego projektu SVN. Nadal jestem z SVN, ale moich potrzeb jest niewiele. GIT jest świetny do większych projektów.
dyasta
3
Najnowsze klienty svn nie potrzebują .svnfolderu w każdym podkatalogu. To „naprawia” błąd kopiowania, zanim to nastąpi.
Edwin Buck
4

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.

seedg
źródło
3

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

Omar Kooheji
źródło
Jednak obsługa systemu Windows naprawdę wymaga trochę pracy. Nie tyle, że nie całkiem z radością korzystałem z niego w całym moim ostatnim programowaniu w systemie Windows (z którym robiłem całkiem sporo), czy coś w tym rodzaju, ale nadal ...
SamB
Prawie w 100% przypadków w systemie operacyjnym ludzie „stworzyli to [dowolne oprogramowanie], ponieważ nie podobało im się nic innego na rynku”.
WhyNotHugo
@Hugo Z otwartym oprogramowaniem, jeśli spodobało im się coś innego na rynku, włożyliby w to wkład, zamiast tworzyć coś nowego.
yingted
To wcale nie jest odpowiedź na pytanie
Albert van der Horst
@AlbertvanderHorst Nie, nie, pytanie zostało udzielone w czasach dzikiego zachodu SO, kiedy nikt nie wiedział nic lepszego i zaoferował alternatywę. Kłócący się w pośpiechu wygląda na to, że popełniłem też błąd w nazwie Canonical. Wstydź się!
Omar Kooheji,
3

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.

Robert Gould
źródło
1
Tak, działa pięknie. Zainstalowałem go przez MacPorts i używam go codziennie.
Greg Hewgill
To robi. Jest świetny na każdym systemie opartym na POSIX (Unix, Linux, Solaris, BSD itp.). Problem dotyczy tylko systemu Windows.
Oli
a git-gui i gitk prawdopodobnie działają tak samo w systemie OS-X jak w systemie Linux i Windows. W przeciwieństwie do tortoiseSVN, który AFAIK jest przeznaczony tylko dla systemu Windows?
David Schmitt
@David Schmitt: cóż, tortoisesvn.tigris.org nazywa to „rozszerzeniem powłoki systemu Windows dla Subversion”, więc zakładam, że tak ;-).
SamB
@Robert: jakie były Twoje doświadczenia z Git na OS X?
David Schmitt
2

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.

Pierre
źródło
1

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.

Phil Hannent
źródło