Извините, если это дубликат, я посмотрел.
Мы переезжаем в Git. В Subversion я привык иметь папки \ trunk, \ branch и \ tags.
С Git переключение между ветвями заменит содержимое рабочего каталога, так что я прав, если предположить, что способ, которым мы привыкли работать, не применим к Git?
Я предполагаю, что у меня будет папка репозитория с, возможно, gitignore и readme.txt, затем папки для проектов, составляющих репо, и все.
Ответы:
У вас будет «ствол», теперь называемый «мастер», у вас будут «ветви», теперь называемые «головками», и у вас будут «теги», все еще называемые «тегами», но они не будут папками , они будут » refs ", обозначает ревизии, которые находятся в отдельном пространстве имен внутри репозитория.
Subversion и Git имеют разные способы ветвления. Основная модель Subversion - иметь дерево каталогов с единой глобальной временной шкалой, и если вы хотите выполнить ветвление, вы копируете поддерево в другой каталог.
С другой стороны, у Git есть дерево каталогов с ревизиями, каждая из которых определяет своих родителей, но у каждой ревизии может быть несколько родителей (слияние) и несколько дочерних (ветви). Таким образом, вместо наличия каталогов для веток, вы получаете независимо созданные ревизии. «Ссылки» - это просто имена, связанные с последней ревизией для данной «ветки».
Эта разница является фундаментальной для распределенного контроля версий. Git (и другие распределенные системы) не имеет каких-либо центральных полномочий для сохранения истории линейной, поэтому ревизии могут создаваться независимо в нескольких репозиториях, не зная друг о друге, и система должна их учитывать. Оказывается, обобщение значительно упрощает ветвление и слияние.
Обратите внимание, что в Git ревизии отсутствуют ни в одной ветке. Они просто есть и ветки содержат их. Но как только ветвь слилась или окажется мертвым переулком, вы можете просто удалить указатель «ref», указывающий на него, и полностью забыть о нем (если вы отбросите старые испытания, они будут в конечном итоге собраны с мусором git gc). Это поможет вам избежать затопления в старых экспериментах, о которых они больше не помнят.
Просто думайте о Git как о трехмерном представлении тех же данных, которые вы видите в 2D в SVN - т.е. с SVN вы разветвляете свой корень, и он выглядит как копия, показанная как новая папка в дереве. С Git, когда вы разветвляетесь, он выглядит как копия, показанная как «слой» поверх существующего дерева. Как только вы понимаете, что это довольно легко осмыслить разницу.
С SVN вы все еще можете работать так же, как Git - переключение между ветвями заменит одно представление кодовой базы на разветвленное представление, это применяется независимо от того, используете ли вы svn switch или git checkout.
Очевидно, что вы можете получить копию ветки в SVN, проверив ветку в ее расположении в папке, что аналогично клонированию git-репо в другое место на вашем диске.
То же относится и к тегам - вы можете пометить версию git или создать ветку для релиза. Теги SVN аналогичны ветвям, единственное соглашение, которое они называют «тегами». Вы можете пометить (ну, записать номер редакции) репозитория SVN, чтобы получить снимок релиза.
Различия между git и svn больше связаны с тем, как происходит регистрация и извлечение, а не с основами контроля версий. Представление кода может быть другим (вы никогда не увидите единственное представление дерева кода, которое включает в себя ветки в git, и вы можете разветвить частичное хранилище в SVN, но в конечном итоге это незначительные различия)