Как стать автором
Обновить

Комментарии 36

Под кат, пожалуйста.
чем гит лучше моего svn сервера? для меня это самвй важный вопрос.. я почитал и совсем немножко представляю его отличия, но пока не вижу реальной выгоды. а вы?
Возьмите и попробуйте поработать сами. Иначе тут будет холивар и разговор глухого со слепым.
от меня - не будет.. я же вашего субъективного мнения спрашиваю, мне интересно. просто для мало того, что ror переехал на git :) я хочу понять зачем это стоит делать кроме "расширения кругозора", потому что svn и git - вторичные инструменты и просто так переходить не хочется.
Мое мнение: гит проще, быстрее и надежнее.
насчет проще с oleganza не соглашусь, у нас даже после длительной работы с свн вьезжали долго

работа с ветками (мерджи) дествительно гораздо проще
практика с SVN только мешает при переезде на git.
У меня девушки которые ручным тестирование и контентом заведуют вполне справляются.

Картинку добавить, css поправить, простенький шаблон поменять. Потом все закоммитить и вылить на сервер. Не преувеличивайте сложность.
Для меня было две практических причины перейти с svn на mercurial для своих проектов:
- в distributed scm намного лучше дела с бранчами
- не надо париться с бекапами — каждая рабочая копия уже независимый бэкап репозитория
по поводу первого пункта, нельзя–ли поподробнее? Что конкретно намного лучше ? Я конечно про сравнение с svn 1.5

А какая запарка с бэкапами у вас в svn? Это одна комманда в крон, ну или 5 минут на организацию полного зеркала
Сразу скажу — имхо, действительно серьезные и объективные преимущества у DVCS есть svn есть только в достаточно распределенных проектах. Ну или люди говорят, удобно в большой команде — более точно можно контролировать доступ к основной ветке. Вроде того что у каждого тимлида по ветке, они сливают туда изменения от подчиненных, делают review, а потом Самый Главный Лид мержит в главную ветку.

Что касается меня: да, 1.5 я еще не пробовал толком — для своих нужд уже к меркуриалу привык, а на работе, прости господи, VSS. Меркуриал определенно мне нравится скоростью, маленьким размером репозитория, и тем что бранч в общем-то можно создать тупо скопировав папку с исходниками.

С зеркалами очень просто, для этого нужно два компутера, а у меня репозиторий на VDS и 3-4 компутера с которых я работаю, и ни один из них не включен круглосуточно.
Лично мне Git не нравится. Собственно - git это куча скриптов, бинарников и тому подобного которое работает как одна большая scm. Плюс, не нравится что базу время от времени нужно пересобирать что бы оно не тормозило и не жрало много места.
Из личных предпочтений - Mercurial. Во первых нормально работает на разных платформах (да да, знаю, Git уже тоже доточили напильником для винды). Во вторых - быстро работает. В третьих - command-line интерфейс не сильно отличается от SVN. В четвертых - написан на питоне, достаточно компактен, кода относительно не много (меньше чем в Git, Bazaar и SVN раза в два при той же функциональности). Работает чуть медленнее Git, но быстрее Bazaar. Есть виндовый гуй а-ля TortoiseSVN. Trac умеет работать с репозиторием.

P.S. У Mercurial и Git общие корни - все выросло из обсуждения в linux-kernel mailing list. Просто ребята не договорились как делать scm и пошли своими дорогами.
Чтобы не было холивара, предупрежу всех читателей, что тема Git vs. Mercurial уже обсуждалась в миллионе блогов. Ищите их в гугле и ругайтесь там.
Я не собираюсь разводить холивар, ни в коем случае. Просто высказал свое мнение.
У нас на проекте использовался svn + track. Почти год назад перешли на git и жить стало легче. Так как распределенная разработка, то если пропадает связь до сервера, не беда, есть локальный репозитарий, на своем компьютере. Когда линк поднимается, можно сделать push на сервер.
"git stash"/"git stash apply" - вещь супер.
Редкий пример хорошей статьи. Спасибо.
> Уже были статьи про основы гита, были и статьи про внутреннее устройство репозитория.
Хотелось бы ссылочек, если можно.
добавил немножко.
Спасибо!
Вместо gs лучше использовать gst, ибо

$ gs --help
ESP Ghostscript 8.15.4 (2007-03-14)
Разумно. Но я пока что с gs проблем себе не создал. Буду иметь в виду.
Кстати, помнишь ты говорил, что "export PS1='`__git_ps1 "%s"` \w \$ '" работает только в последней версии.
маленькое замечание к 3): вместо git-stash && git-checkout && git-stash apply можно использовать git-checkout -m
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, добавил в список ссылок.
У Вас, надо сказать, намного понятнее для неподготовленного читателя, т.е. для меня
Спасибо большое за статью. Будет очень интересно почитать про git-svn.
пользуюсь SVN
git отпугивает тем, что воодит новые сущности, надобность в которых сильно не ощущается
хотя сама идея децентрализованного хранилища и работы с локальным репозиторием кажется правильной
хотелось бы прочитать статью про переход на git с svn, но не типа "вместо svn up набирайте git up", а с описанием различий в базовых понятиях и подходах к работе с хранилищем.

спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо. Попробую.
Дело в том, что я только пол года назад внедрил в своём проекте SVN: это не было слишком тягостно, но не без сопротивления "среды" ))
Если теперь я приду и скажу "SVN - это прошлый век, давайте юзать git", меня побъют ))
Внимание вопрос: как менеджерам и рядовым сотрудникам объяснить, зачем им нужно (ли) перейти с SVN на git? зачем им тратить своё время на освоение новой логики и технологии, когда они только что освоили и привыкли к SVN?
НЛО прилетело и опубликовало эту надпись здесь
интересно, а усложняется ли (или вообще возможна ли) работа с git, если в репозитории нужно учитывать права доступа пользователей? т.е. разные люди имеют доступ к только к определенным директориям репозитория.
Нет, такое гит не поддерживает: вы клонируете весь репозиторий и делаете с ним, что хотите. Поддерживается лишь хранение юникс-атрибутов rwx, но это не ограничивает доступ.

Если хотите разграничить доступ — разбивайте проект на разные репозитории, кладите на защищенный сервер и ограничивайте доступ к каждому репозиторию (например, с помощью gitosis, а можно и просто юникс-средствами ограничить доступ к определенным директориям на сервере).

В следующий раз нужно написать пару слов о комфортной работе с git-submodule и git-svn.

Есть примерные сроки? =)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.