Pracuję w dziale, w którym nikt wcześniej nie używał kontroli źródła, w tym ja.

Próbuję rozwinąć koncepcję. Spędziłem trochę czasu badając SVN. Nauczyłem się kilku podstaw. Mogę tworzyć / aktualizować / kasować / zatwierdzać za pomocą wiersza poleceń i Tortoise. Zaczynam się uczyć, jak oznaczać i rozgałęziać, ale wciąż dużo mylić na temat konfliktów między gałęziami a pniem itp. Wciąż się uczę, ale nie mam fizycznej osoby, która mogłaby mi coś pokazać. To wszystko z książek / samouczków oraz prób i błędów.

Z tego, co przeczytałem online, wydaje gitsię, że lepiej wiedzieć, ale jest to również bardziej skomplikowane. Nie chcę się przytłaczać. Czy powinienem kontynuować opanowanie svn przed przejściem do git, czy też mądrzej byłoby po prostu przejść teraz do git?

Czy są zalety i wady obu podejść?

Nie

Git tak radykalnie różni się od SVN, że ci nie pomoże. Jeśli już, będziesz szukał poleceń „aktualizuj” i „zatwierdzaj” i zastanawiasz się, dlaczego wszystko jest inne.

Zacznij od Git od dołu do góry i stamtąd.

Kontrastowanie standardowego scentralizowanego systemu aktualizowania / zatwierdzania wersji z Git przypomina porównywanie magistrali z transportem masowym. Autobus zabierze Cię (i wszystkich innych) z punktu A do punktu B tą samą trasą. Transport zbiorowy zabierze Cię z punktu A do punktu B dowolną trasą.

Sam rozproszony ma wady, o których powinieneś wiedzieć. Aby utrzymać wszystkich na tej samej stronie, potrzeba więcej pracy. Oferuje jednak ogromny wzrost elastyczności.

Skróty weryfikacji a liczby

Ktoś wspomniał, że Git używa skrótów SHA1, podczas gdy Hg używa liczb.

Po pierwsze rzadko (jeśli w ogóle) musisz radzić sobie bezpośrednio z hashami w codziennych zatwierdzeniach / pociągnięciach. Musisz wyciągnąć dziennik i wyciągnąć skróty, jeśli robisz diff lub niektóre z bardziej skomplikowanych elementów.

Dzięki Git każdy ma takie same skróty. Różne repozytoria nie mają różnych numerów zatwierdzeń i wszyscy są na tej samej stronie. Z Hg jest tak mniej. W praktyce, jeśli musisz wyciągnąć skróty zatwierdzania i pracować z nimi (albo w celu porównania lub przejścia na osi czasu kodu), łatwiej jest zsynchronizować się z innymi ludźmi, gdy masz skróty zamiast liczb.

Nie, proszę, nawet się nie przejmuj.

Poważnie, zacznij od DVCS. Fakt, że SVN jest popularny, nie czyni go standardem. Linus Torvalds powiedziałby ci, że może zepsuć twój mózg .

Przeczytaj ten wspaniały artykuł / wprowadzenie Joela Spolsky'ego zatytułowany Subversion Re-education .

Być może zainteresuje Cię także inne pytanie: Jestem maniakiem Subversion, dlaczego powinienem rozważyć lub nie rozważyć Mercurial, Git lub innego DVCS?

Wybieranie między DVCS

Osobiście używam zarówno rtęci, jak i git, i uważam, że ważne jest, aby znać oba. Zalecana lektura na ten temat to Git vs. Mercurial: Proszę się zrelaksować (zobacz przykład git-addremove). Myślę, że dwa cytaty z tego artykułu.

Jeśli chodzi o git:

Filozofia projektowania Git jest jednoznaczna z Uniksem: w przeciwieństwie do Subversion, CVS lub Mercurial, git nie jest jednym monolitycznym plikiem binarnym, ale mnogością pojedynczych narzędzi, począwszy od poleceń „porcelany” wysokiego poziomu, takich jak git-pull, git-merge i git-checkout do komend niskiego poziomu, takich jak git-Apply, git-hash-object i git-merge-file. Podobnie jak MacGyver, możesz robić wszystko, czego potrzebujesz dzięki Git - obejmuje to całkowicie niesamowite silniki Wiki, narzędzia do śledzenia problemów, systemy plików, narzędzia sysadmin - wszystko to bez naprawy bezpieczników.

W odniesieniu do rtęci:

Programiści, którzy lubią utrzymywać swój system w czystości, prawdopodobnie docenią fakt, że hg instaluje jeden plik binarny, w przeciwieństwie do 144, które składają się na git, a programiści, którzy uważają, że zdolność gita do edytowania twoich poprzednich zatwierdzeń jest kretyńska, niepotrzebna i niebezpieczna, docenią prostota hg zapewnia pominięcie tej konkretnej funkcji.

Na github można znaleźć wiele projektów, a git ma większą moc, ale może być także nieco onieśmielający dla początkujących, szczególnie użytkowników Windows. Istnieje również bitbucket (ekwiwalent githuba dla rtęci).

Moja rada: zacznij od rtęci i jak tylko poczujesz się z tym dobrze, wybierz git; nie chodzi o narzędzia, chodzi o ludzi, z którymi pracujesz .

To, co uważam za rzeczywiste i praktyczne zastosowanie subversion, to nie praca z innymi ludźmi, ale być może w celu zaimplementowania aktualizacji dla aplikacji produkcyjnych, oto dlaczego:

• Obecnie svn jest prawie zainstalowany w większości dostawców hostingu
• Ma dobrą obsługę podprojektów (teraz jednak adresowalną w git i hg). svn upa Twój projekt i jego zależności zostaną zaktualizowane.

Cytując Thorbjørn w tym innym wątku :

DVCS są dla Subversion, czym Bittorrent jest dla ftp

Edycja : Jeśli istnieje VCS, o którym powinieneś wiedzieć przed Git, może to być Mercurial (o wiele bardziej przyjazny interfejs CLI i dobrze jest zapoznać się z koncepcjami rozproszonymi). Ta rada dotyczy szczególnie osób pochodzących z Subversion, ponieważ CLI jest również w pewnym stopniu podobny. Rozproszona kontrola wersji może być łatwiejsza do nauczenia niż scentralizowana kontrola wersji, ponieważ martwisz się tylko o instancję repozytorium, a nie o części klienta i serwera oddzielnie .

Powinieneś uczyć się, co zamierzasz wykorzystać. Git jest popularny, podobnie jak Mercurial również cieszył się popularnością. Git / Mercurial to rozproszone systemy kontroli źródła.

Najważniejszą rzeczą przy wprowadzaniu nowej koncepcji do zespołu (i szkoda, że ​​kontrola wersji jest uważana za nowy temat dla zbyt wielu zespołów), pomaga nakreślić cele i kryteria oceny. Nie musisz być w tym zbyt formalny, ale zadaj sobie następujące pytania:

• Jaki jest cel kontroli wersji w naszym zespole. Tak, wszystkie systemy kontroli wersji warte czegoś pozwolą ci wrócić do historii i zobaczyć, co zmieniło się w danym pliku. Czy zamierzasz go jednak wykorzystać do stworzenia nowych wersji? (skinąć głową, chcesz tego). Jest to 2-3-liniowe oświadczenie dotyczące wizji tego, co chcesz osiągnąć.
• Czy Twój zespół jest przyzwyczajony do posiadania własnego lokalnego środowiska pracy, aby później ostrożnie łączyć rzeczy? Jeśli tak, trasa DVCS może być najbardziej sensowna.
• I odwrotnie, czy Twój zespół jest przyzwyczajony do pracy z jednego dysku wspólnego i wszystko jest w ciągłej integracji? Jeśli tak, bardziej sensowny może być bardziej tradycyjny VCS.

Oceniając swoje alternatywy, musisz wziąć pod uwagę ważne rzeczy, które wszystkie VCS muszą zrobić:

• Kod bazowy (oznaczone oddziały, etykiety itp.). Zasadniczo, w jaki sposób uzyskać dokładny kod źródłowy użyty w wydaniu projektu.
• Uzyskaj lokalne zmiany na serwerze centralnym. Musi istnieć wiarygodna kopia kodu - bez względu na to, czy korzystasz z DVCS, czy ze standardowego VCS. Każde narzędzie traktuje ten proces inaczej.
• Pobierz zmiany na centralnym serwerze do swojej lokalnej kopii.
• Jak radzić sobie ze zmianami eksperymentalnymi. VCS pozwalają ci być bardziej śmiałym z proponowanymi zmianami bez łamania głównego kodu źródłowego projektu. Systemy DVCS i standardowe systemy VCS podchodzą do tego zupełnie inaczej - jeden z nich będzie działał najlepiej dla Twojego zespołu.
• Jak skonfigurować i skonfigurować serwery?
• Czy potrzebujesz uwierzytelnienia? Jeśli tak, to w jaki sposób upewnisz się, że faktycznie mogą to zrobić tylko osoby, które mogą wprowadzać zmiany?

Na koniec dokonaj szybkiej oceny, aby ustalić, czy standardowe systemy VCS czy DVCS będą najlepsze dla Twojego zespołu. Musisz wybrać narzędzie, które zapewni najmniej bólu, w przeciwnym razie prawdopodobnie nie zostanie ono adoptowane. Następnie oceń alternatywy, które najlepiej pasują do twoich potrzeb.

Na koniec dowiedz się, czego zamierzasz użyć.

Myślę, że wiele osób uważa, że ​​git jest bardziej skomplikowany niż SVN, ponieważ jest inny. Po pewnym czasie korzystania z subversion (lub cvs itp.) Mentalne przełączenie trybów na model DVCS może być trudne. Opierając się na tym, powiedziałbym, że może ci się spodobać badanie tradycyjnych VCS, takich jak subversion, w połączeniu z badaniem DVCS, takich jak git.

Chociaż git jest moim preferowanym VCS, powiedziałbym, że prawdopodobnie najlepiej jest nauczyć się również subversion. Po pierwsze, wciąż istnieje wiele repozytoriów subversion i cvs, z którymi być może będziesz musiał wchodzić w interakcje jednego dnia, a także będziesz lepiej rozumieć dokładne zalety i wady DVCS w porównaniu z tradycyjnymi VCS.

Nauka svn, a następnie git przyniosłaby efekt przeciwny do zamierzonego

Oto kilka powodów:

• Gits radykalnie różni się od svn. Git rozprasza się, a svn jest klientem / serwerem.
• Różne znaczenia są przypisane do tych samych słów. Na przykład „git checkout ...” ma inne znaczenie niż „svn checkout ...”
• Rozgałęzienie jest inne. Git ma taką koncepcję gałęzi „tematycznych”, które są tanimi gałęziami lokalnymi, których svn nie obsługuje.
• Git ma dodatkowe miejsce, zwane indeksem, które znajduje się między działającym drzewem a twoim repozytorium. Svn nie ma indeksu. Za pomocą git zmiany przenieś z drzewa roboczego do indeksu do repozytorium.

Moja rada to po prostu nauczyć się git.

Niektóre rzeczy są zasadniczo takie same w GIT i SVN, a niektóre nie.

Utwórz / aktualizuj / kasy / zatwierdzenia

Ogólnie rzecz biorąc, powinieneś go łatwo podnieść.

jak oznaczać i rozgałęziać, ale nadal wiele mylić na temat konfliktów między gałęziami i pniem itp

Różni się między nimi.

Nie mówiąc, że powinieneś lub nie powinieneś się teraz zmieniać (myślę, że to twój telefon), chciałem tylko to podkreślić, ponieważ jest to coś, co należy wziąć pod uwagę. Jeśli na pewno chcesz wypróbować Git, możesz zdecydować się teraz na zmianę, aby zaoszczędzić sobie nauki czegoś w SVN, co jest inne w Git.

Łał; 12 odpowiedzi i wszyscy wciąż pytają ...

Nie, Subversion nie jest warunkiem wstępnym dla Gita.

Nie ma czystego mapowania między Subversion a Git - jeśli planujesz nauczyć się obu, będziesz musiał po prostu cierpieć z powodu tego, że używają tych samych terminów dla różnych działań. (I różne warunki dla tych samych działań.)

• svn commitjest czymś innym niż git commit.
• gałęzie w svn i git są bardzo różne
• repozytorium svn jest bardziej jak zdalny git (ale tak naprawdę nie)
• repozytorium git przypomina bardziej kopię roboczą svn (ale nie jest tak naprawdę)

Są to dwa narzędzia podzielone przez wspólny język.

Twoje pytanie i większość innych odpowiedzi zakładają, że git jest rodzajem svn ++; „Lepszy svn”. To nie jest Oba są różnymi narzędziami, które działają w tej samej przestrzeni, jak samochód i motocykl.

Sugeruję, abyś wybrał jeden, opanował go i zaczął używać go w swoim zespole. Nauka kontroli wersji będzie trudna dla osób, które wcześniej jej nie używały. Twój VCS będzie ważną częścią twojej infrastruktury, a uczenie się zaufania wymaga budowania nowych nawyków pracy. To zajmuje trochę czasu.

(Tak czy inaczej, upewnij się, że sysadmini utworzyli kopie zapasowe głównego repozytorium - utrata kontroli źródła byłaby katastrofalna).

Prawdopodobnie nie - istnieją wystarczające różnice między serwerami a serwerami rozproszonymi, które prawdopodobnie spowodowałyby dalsze zamieszanie.

Od samego początku kieruj się dobrymi praktykami z DVCS, jak od zera, a prawdopodobnie będziesz o wiele szczęśliwszy.

Idź spójrz na Mercurial (jeśli nie chcesz być przytłoczony).

Git jest tylko nieznacznie bardziej skomplikowany niż Subversion, ponieważ w Git istnieje różnica między zatwierdzaniem a wypychaniem do centralnego repozytorium.

Warto nauczyć się Git, gdy masz szansę na niezadowolenie swojego umysłu z Subversion.

Nie sądzę, aby zrozumienie Subversion było konieczne, aby zrozumieć Git.

Największą różnicą z Git i Mercurial z Subversion, przynajmniej dla mnie, jest to, że masz lokalne repozytorium, z którym pracujesz, logujesz się tam i tam, aż twój kod działa, kasujesz z centralnego repozytorium, naprawiasz wszelkie konflikty i zamelduj się ponownie i prześlij na serwer.

Naprawdę lubię git w środowisku Unix (Linux, MacOS X). W systemie Windows jest nieco zhackowany. Rozważę Mercurial, jeśli mam Windows w równaniu.

Podobały mi się twoje historie, spróbuj SCCS, RCS, CVS, Subversion, a następnie użyj czegoś użytecznego, takiego jak Git lub Mercurial.

Git i Mercurial są ekwipotencjalne, dużą zaletą Git jest github . Ale jeśli nie chcesz zlecać kontroli wersji, github nie jest już w równaniu.

Systemy kontroli wersji mają coś wspólnego z językami programowania, ponieważ pierwszy, którego się uczysz, zajmie najwięcej czasu. Następnie wybór nowego jest tylko kwestią poznania, w jaki sposób wyrażane są podstawowe pojęcia w nowym systemie.

Możesz nauczyć się Git teraz i zainwestować czas w naukę Suvbersion później, jeśli zajdzie taka potrzeba.

Nie. Pobierz Git, stwórz konto github i baw się przez kilka dni, rozwidlając repozytorium itp. Git jest dość trywialny, aby zacząć na nim działać. Naucz się 5 lub 6 poleceń bash, a będziesz mógł wykonać wszystkie niezbędne zadania. Ogólnie wolę „idiotoodporność” GUI, ale Git Bash jest tak łatwy, jak to tylko możliwe. Ponadto Git Gui jest całkiem przyzwoity, jeśli wolisz tę trasę. Naprawdę nie widzę korzyści płynących z nauki SVN. Jakiś czas temu przeszedłem przez okres, w którym oceniałem kilka różnych systemów kontroli wersji pod kątem nowego projektu open source. Wypróbowałem SVN, Bazaar, Git i kilka innych i nauczyłem się podstaw każdego z nich. YMMV, ale Git był zdecydowanie najłatwiejszy. Nauka SVN również nie jest niczym złym, ale tak naprawdę nie pomoże ci nauczyć się Git.