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 git
się, ż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ść?
Odpowiedzi:
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.
źródło
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:
W odniesieniu do rtęci:
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:
svn up
a Twój projekt i jego zależności zostaną zaktualizowane.Cytując Thorbjørn w tym innym wątku :
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 .
źródło
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:
Oceniając swoje alternatywy, musisz wziąć pod uwagę ważne rzeczy, które wszystkie VCS muszą zrobić:
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ć.
źródło
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.
źródło
git-svn clone
do interakcji z repozytorium.Nauka svn, a następnie git przyniosłaby efekt przeciwny do zamierzonego
Oto kilka powodów:
Moja rada to po prostu nauczyć się git.
źródło
Niektóre rzeczy są zasadniczo takie same w GIT i SVN, a niektóre nie.
Ogólnie rzecz biorąc, powinieneś go łatwo podnieść.
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.
źródło
Ł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 commit
jest czymś innym niżgit commit
.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).
źródło
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).
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło