Я пользуюсь SVN уже много лет и не могу сказать, что полностью этому доволен. Несколько дней назад мой партнер попросил меня взглянуть на git, сказав, что «у него лучшая производительность, проще слияние и ветвление».
Я читал статьи о сравнении git и SVN, и был бы счастлив, если бы люди суммировали плюсы и минусы, используя обе системы контроля версий.
Сейчас я изучаю людей, которые перешли с одной системы на другую и слышат субъективные мнения.
Я знаю по себе, что мне очень нравится, как работает SVN, имея один центральный репозиторий, из которого люди могут оформлять заказ, зная, что я могу развернуть из него живую копию для разработки и живую производственную копию, но иногда у нас возникают головные боли, связанные с конфликтами сортировки или другими ошибками и Каждый раз, когда нам нужно сравнить или просмотреть историю файла, нам приходится иметь дело с задержкой в сети.
С другой стороны, наличие распределенной платформы также кажется головной болью, как вы можете контролировать доступ? у вас есть один центральный репозиторий, из которого вы загружаете и обновляете?
Спасибо, что пролили свет на эту проблему.
Вы пытаетесь сравнить эти два инструмента со стороны системного администратора или программиста? Если вы смотрите на это с точки зрения программиста, возможно, вам следует спросить об этом в stackoverflow. Или даже лучше, возможно, вам стоит взглянуть на то, о чем уже спрашивали "git svn".
Особенность git и svn в том, что это не предложение "или-или". Вы можете запустить репозиторий SVN, и ваши разработчики могут использовать git-svn чтобы взаимодействовать с ним, если они думают, что git - лучший инструмент в конкретном случае.
На самом деле нет никаких плюсов в подрывной деятельности через git. Пока git распространяется, каждый может работать из центрального репозитория, используя ветки удаленного отслеживания. git работает быстрее, гибче и действительно работает. Кроме того, вы можете реально работать в автономном режиме, тогда как с Subversion вы не можете фиксировать изменения, если у вас их нет. Вы можете легче работать с отдельными фиксациями в git по сравнению с наличием одного идентификатора фиксации, представляющего состояние репозитория в svn.
Доступ контролируется либо учетными записями пользователей / групп на сервере git (вы должны инициализировать исходный репозиторий с помощью 'git init --bare --shared', чтобы права были установлены соответствующим образом), либо с помощью ключей ssh. Очень детализированный контроль доступа можно настроить с помощью стороннего дополнения gitosis.
Когда вы привыкли к svn, нужно некоторое время, чтобы привыкнуть к работе с git (мы только что прошли через это в моем офисе), но git намного мощнее.
Если вам нужно отличное пошаговое руководство, посмотрите http://progit.org - это полная онлайн-копия книги с открытым исходным кодом.
В моей команде мы находимся в процессе изменения нашей системы управления версиями с svn на git. У Git чуть более сложная кривая обучения, поэтому я начал знакомиться с ним, а затем учил разработчиков, как его использовать. Им необходимо знать все преимущества систем распределенного управления версиями: несколько ветвей, отсутствие центрального репозитория, скорость и т. Д.
Как и у вас, у нас была система для развертывания наших сайтов, поэтому мы держим что-то вроде центрального сервера git, где изменения извлекаются и отправляются с и на машины разработчиков. Наши сайты получают изменения с этого «центрального сервера», а остальная часть процесса развертывания аналогична той, что используется svn.
Мы постарались не смешивать репозитории svn и git, начав переносить наши второстепенные сайты и создавать новые репозитории git для основных сайтов, как если бы они были новой версией. Доступ осуществляется с помощью ключей ssh. Также мы используем gitweb в качестве веб-интерфейса (наша система svn основана на http)
Это работает, это не переход от одного дня к другому, и мы стараемся, чтобы разработчики воспринимали это изменение не как раздражение, а как новый навык, чтобы изучить инструмент, который в конечном итоге улучшит нашу собственную систему.