Przepraszam, jeśli to duplikat, szukałem.
Przeprowadzamy się do Git. W Subversion przyzwyczaiłem się do folderów \ trunk, \ oddziałów i \ tags.
W przypadku Git przełączanie między gałęziami zastąpi zawartość katalogu roboczego, więc czy mam prawo założyć, że sposób, w jaki działaliśmy, po prostu nie ma zastosowania w przypadku Git?
Domyślam się, że miałbym folder repo z może gitignore i readme.txt, a następnie foldery projektów, które składają się na repo i to wszystko.
Odpowiedzi:
Będziesz miał „pień”, teraz nazywany „master”, będziesz miał „odgałęzienia”, teraz zwane „główkami”, i będziesz miał „tagi”, nadal nazywane „tagi”, ale nie będą to foldery , będą to „ refs ”, oznacza etykiety wersji, które znajdują się w oddzielnej przestrzeni nazw w repozytorium.
Subversion i Git mają różne sposoby rozgałęziania. Podstawowym modelem subwersji jest posiadanie drzewa katalogów z pojedynczą globalną osią czasu, a jeśli chcesz się rozgałęzić, skopiuj poddrzewo do innego katalogu.
Z drugiej strony Git ma drzewo katalogów z wersjami, z których każda definiuje swoich rodziców, ale każda wersja może mieć wielu rodziców (połączenie) i wiele dzieci (gałęzie). Zamiast więc katalogów dla oddziałów, otrzymujesz niezależnie utworzone wersje. „Referencje” to tylko nazwy związane z najnowszą wersją dla danego „oddziału”.
Różnica ta ma zasadnicze znaczenie dla rozproszonej kontroli wersji. Git (i inne systemy rozproszone) nie ma żadnego centralnego uprawnienia do utrzymywania historii na poziomie liniowym, więc zmiany mogą być tworzone niezależnie w wielu repozytoriach bez wiedzy o sobie, a system musi je uwzględnić. Okazuje się, że uogólnienie znacznie ułatwia rozgałęzianie i scalanie.
Zauważ, że w Git wersje nie są w żadnej gałęzi. Po prostu są, a gałęzie je zawierają. Ale kiedy gałąź zostanie scalona lub okaże się martwą uliczką, możesz po prostu usunąć „ref” wskazujący na nią i całkowicie o niej zapomnieć (jeśli odrzucisz stare próby, zostaną one ostatecznie usunięte git gc). Pomaga to uniknąć zalania starych eksperymentów, których nikt już nie pamięta.
Pomyśl o Git jako widoku 3D tych samych danych, które widzisz w 2D w SVN - tzn. W SVN rozgałęziasz swój katalog główny i pojawia się on jako kopia pokazana jako nowy folder w drzewie. Dzięki Git, kiedy się rozgałęziasz, pojawia się jako kopia pokazana jako „warstwa” na twoim istniejącym drzewie. Kiedy zdasz sobie sprawę, że dość łatwo jest pojąć różnicę.
Za pomocą SVN nadal możesz pracować tak samo jak Git - przełączanie między gałęziami zastąpi pojedynczy widok bazy kodu widokiem rozgałęzionym, dotyczy to niezależnie od tego, czy używasz przełącznika svn, czy kasy.
Oczywiście możesz uzyskać kopię gałęzi w SVN, sprawdzając gałąź w jej lokalizacji folderu, co jest równoznaczne z klonowaniem repozytorium git w innej lokalizacji na dysku.
To samo dotyczy tagów - możesz oznaczyć wersję git lub utworzyć gałąź dla wydania. Tagi SVN są takie same jak gałęzie, a ich jedyna konwencja nazywa się „tagami”. Możesz oznaczyć (cóż, nagrać numer wersji) repozytorium SVN, aby również uzyskać migawkę wydania.
Różnice między git i svn są bardziej związane z tym, jak się meldują i kasa, a nie z podstawami kontroli źródła. Widok kodu może być inny (nigdy nie zobaczysz jednego widoku drzewa kodu zawierającego gałęzie w git i możesz rozgałęzić częściowe repozytorium w SVN, ale są to ostatecznie niewielkie różnice)