Решился, наконец, и перевел свои домашние проекты с Svn на Git.Что мне нравится в Git больше всего, это как в нем сделаны branches. В отличие Svn или того же Perforce, где branch это копия всего кода в другом каталоге, в Git это новое измерение, альтернативная реальность. Можно быстро и легко переключаться между ними. Что очень удобно, если хочешь попробовать какую-нибудь новую идею, просто создаешь новый branch, пробуешь в нем, в любое время можно переключиться обратно.
А еще мне нравится GitX (для Mac-а), в которой хорошо видна вся история и легко переключаться на любой commit любого branch.
В Svn я обычно не пользовался branch-ами, а просто отыгрывал изменения назад. И как-то все было неудобно, даже найти нужную revision нелегко. Единственное, что мне нравилось в Svn, что вся история не хранится на каждом клиенте, а только на сервере. Но в Git 1.9 это, кажется, пофискили и можно сделать "git clone --depth 1" и получить только последнюю версию всех файлов, а потом сделать commit и "git push" обратно в репозитарий.
Репозитарий я храню на домашнем сервере Synology, в котором Git ставится как пакет.
Git уже содержит в себе "git svn" команду, которая позволяет легко импортировать всю историю в новый Git репозитарий. Что я и сделал в субботу для всех своих проектов, разбив большой Svn репозитарий на несколько независимых Git репозитариев (это тоже легко сделать в git svn).
Короче, пока доволен. Git+GitX - то, что надо для дома, для семьи.
GitX надо брать не с сайта разработчика, где он завис на ранней версии, а на Github, где его продолжают доводить до ума.
10 comments:
Спасибо, мне было интересно. Хотя у меня проекты и ограничены одним компьютером, но может быть полезна поддержка версионности, а также навык пользования стандартным инструментом.
Git вполне удобен на одном компьютере. Командая строка, правда у него несколько эклектичная, но сейчас много UI оболочек.
А mercurial пробовали? Очень похож на git, но комфортнее для меня. У меня почти все проекты на нем, но во многом это в силу исторических причин, когда много проектов держалось на http://bitbucket.org/, который в те далекие времена поддерживал только mercurial.
Нет mercurial не пробовал. У нас в MS объявлен переход на Git, точнее на VSO Git, и я решил немного попрактиковаться на домашних проектах. На самом деле я сейчас развиваю и поддерживаю то, что в MS произвели из Perforce двухтысячного года. Но сверху решили переходить на Git. Решили то давно, но перейти не просто, много кода написано вокруг. А дома оказалось перейти очень просто. У меня дома нет ни build lab, ни code mining.
Пользовался VSS под WinXP и СVS под Linux, где лет 5 назад разок команды попутал с катастрофическими последствиями для практически завершённого проекта.
После перехода на SVN с CVS мне как раз показалось более правильным, что ветка - это другой каталог и никаких альтернативных реальностей и прочих лишних сущностей. Проблемы переключиться на другую ветку не понимаю. Но, видимо, на вкус и цвет...
Я так думал несколько лет назад. А как попробовал без лишних каталогов, мне очень понравилось.
Я вижу, что понравилось :) Но в чём преимущество этих сущностей в отдельном виде так и не понятно.
Бранч в каталоге - идея того времени, когда никакого source control вообще не было. Это как хранить предыдущие версии файла в других файлах.
В Svn я часто пользовался update to revision. Выбираешь ревизию и "svn update -r124". Можно переключаться вперед и назад. В Git можно так переключиться на любой коммит из любого бранча, что удобно.
Кроме того, часто билд и тесты заточены на определенные каталоги, и не хочется менять пути, чтобы попробовать прогнать тест в других бранчах. Все можно, конечно, сделать, сделать гибкую систему конфигурации путей, и пр. Можно вообще хранить все ревизии в каталогах по именам этих ревизий и вообще обойтись без Svn или Git, я когда-то так и делал, хранил zip-файлы с ревизиями. Но приятно, когда source control решает проблему за тебя.
Брр. Бранч в любом случае имеет некий уникальный идентификатор. Хотя бы потому, что иначе с ним ничего нельзя сделать. Приятность svn именно в том, что все бранчи, теги и файлы имеют общее пространство имён и поэтому синтаксис команд упрощён до предела: путь да ревизия. На каталоги в рабочей копии это не влияет вообще никак. Хочешь - вытаскивай бранчи в отдельные каталоги. Хочешь - переключай уже вытащенный бранч (причём не обязательно весь, можно любое его поддерево) на другой, причём не обязательно того же продукта и репозитория. Разумеется, локальный дифф от текущей базы при этом сохраняется и будет примёржен к новой базе.
Ну вот почти целиком слизаный пример из svn help switch:
"svn switch ^/branches/1.x-release -r125" - если структура в репозитории стандартная, то это будет переключение текущего каталога (можно и другой указать) на бранч 1.x-release и одновременно ревизию 125.
В общем, пока не убедительно.
Post a Comment