it-swarm.com.ru

Должен ли я использовать SVN или Git?

Я начинаю новый распределенный проект. Стоит ли использовать SVN или Git и почему?

320
rudigrobler

SVN - это один репо и множество клиентов. Git - это репозиторий с множеством клиентских репозиториев, каждое с пользователем. Он децентрализован до такой степени, что люди могут отслеживать свои собственные изменения локально, не отправляя данные на внешний сервер.

SVN разработан, чтобы быть более центральным, где Git основан на том, что каждый пользователь имеет свое собственное Git-репо, и эти репозитории Push превращаются обратно в центральное. По этой причине Git предоставляет пользователям лучший локальный контроль версий.

Между тем у вас есть выбор между TortoiseGit , GitExtensions (и если вы разместите свой "центральный" git-репозиторий на github, то его собственный клиент - GitHub для Windows ).

Если вы хотите выйти из SVN, вы можете немного оценить Bazaar . Это одна из систем контроля версий следующего поколения, имеющая этот распределенный элемент. Он не зависит от POSIX, как git, поэтому есть встроенные сборки Windows , и его поддерживают некоторые мощные бренды с открытым исходным кодом.

Но вам могут даже не понадобиться такие функции. Взгляните на особенности, преимущества и недостатки распределенных VCS . Если вам нужно больше, чем предлагает SVN, рассмотрите один. Если вы этого не сделаете, вы можете придерживаться превосходной интеграции настольных систем SVN (в настоящее время).

253
Oli

Я никогда не понимал эту концепцию "мерзавец не хорош в Windows"; Я разрабатываю исключительно под Windows, и у меня никогда не было проблем с git.

Я определенно рекомендовал бы git по Subversion; он просто намного более универсален и позволяет "автономную разработку" таким способом, которым Subversion никогда не мог. Он доступен почти на всех мыслимых платформах и имеет больше возможностей, чем вы когда-либо будете использовать.

110
Dark Shikari

Вот копия ответа, который я сделал некоторый дублирующий вопрос с тех пор удален о Git против SVN (сентябрь 2009 г.).

Лучше? Помимо обычной ссылки WhyGitIsBetterThanX , они разные:

один - центральный VCS, основанный на дешевой копии для веток и тегов, другой (Git) - распределенный VCS, основанный на графике ревизий. Смотрите также Основные понятия VCS .


Эта первая часть вызвала некоторые неосведомленные комментарии, притворяясь, что основная цель двух программ (SVN и Git) одинакова, но они были реализованы совершенно по-разному.
Чтобы уточнить принципиальная разница между SVN и Git , позвольте мне перефразировать:

  • SVN - третья реализация управления : RCS, затем CVS и, наконец, SVN управляйте каталоги версионных данных. SVN предлагает функции VCS (маркировка и слияние), но его тег является просто копией каталога (как ветвь, за исключением того, что вы не "должны" ничего трогать в каталоге тегов), и его объединение все еще сложно, в настоящее время основанное на метаданных -данные добавлены, чтобы вспомнить, что уже было объединено.

  • Git - это система управления содержимым файлов (инструмент, созданный для объединения файлов), превратился в настоящую систему контроля версий , основанный на DAG ( Directed Acyclic Graph ) коммитов, где ветви являются частью истории данных (а не сами данные), и где теги являются истинные метаданные.

Сказать, что они не "принципиально разные", потому что вы можете достичь одного и того же, решить одну и ту же проблему, - это просто ложь на многих уровнях.

  • если у вас много сложных слияний, выполнение их с SVN будет более длительным и более подверженным ошибкам. если вам нужно создать много веток, вам нужно будет управлять ими и объединять их, опять же, намного проще с Git, чем с SVN, особенно если задействовано большое количество файлов (скорость становится важной)
  • если у вас есть частичное слияние для незавершенной работы, вы воспользуетесь областью размещения Git (индекс), чтобы зафиксировать только то, что вам нужно, спрятать остальное и перейти к другой ветке.
  • если вам нужна автономная разработка ... хорошо, с Git вы всегда "онлайн", со своим собственным локальным репозиторием, независимо от того, какой рабочий процесс вы хотите использовать с другими репозиториями.

Тем не менее, комментарии к этому старому (удаленному) ответу настаивали:

VonC: Вы путаете фундаментальное различие в реализации (различия очень фундаментальные, мы оба четко согласны с этим) с различием в целях.
Оба эти инструмента используются для одной и той же цели: именно поэтому многие команды, которые ранее использовали SVN, вполне успешно смогли отказаться от него в пользу Git.
Если бы они не решили ту же проблему, эта заменяемость не существовала бы.

, на что я ответил:

"заменяемость" ... интересный термин ( используется в компьютерном программировании ).
Конечно, Git вряд ли подтип SVN.

Вы можете получить те же технические возможности (тег, ветвь, слияние) с обоими, но Git не мешает вам и позволяет вам сосредоточиться на содержимом файлов , не задумываясь о самом инструменте.

Вы, конечно, не можете (всегда) просто заменить SVN на Git "без изменения каких-либо желательных свойств этой программы (правильность, выполненная задача, ...)" (что является ссылкой на вышеупомянутое определение заменяемости ):

  • Один - это расширенный инструмент редактирования, другой - настоящая система контроля версий.
  • Один подходит для небольших и средних монолитных проектов с простым рабочим процессом слияния и (не слишком много) параллельных версий. Для этого достаточно SVN, и вам могут не понадобиться все функции Git.
  • Другой позволяет использовать средние и большие проекты на основе нескольких компонентов ( по одному репо на компонент ), с большим количеством файлов для слияния между несколькими ветвями в сложном рабочем процессе слияния, параллельными версиями в ветвях, модифицированными слияниями, и так далее. Вы можете сделать это с SVN, но вам гораздо лучше с Git.
    SVN просто не может управлять любым проектом любого размера с любым рабочим процессом слияния. Мерзавец может.

Опять же, их природа принципиально иная (что приводит к другой реализации, но это не главное).
Один видит контроль версий как каталоги и файлы, другой видит только содержимое файла (настолько, что пустые каталоги даже не регистрируются в Git!).

Общая конечная цель может быть одинаковой, но вы не можете использовать их одинаково и не можете решить один и тот же класс проблем (по объему или сложности).

77
VonC

2 ключевых преимущества SVN, которые редко упоминаются:

  1. Поддержка больших файлов. В дополнение к коду я использую SVN для управления своим домашним каталогом. SVN - единственная VCS (распределенная или нет), которая не душит мои файлы TrueCrypt (исправьте меня, если есть другая VCS, которая эффективно обрабатывает файлы размером более 500 МБ). Это связано с тем, что сравнения различий передаются в потоковом режиме (это очень важный момент). Rsync недопустим, потому что это не 2-х сторонний.

  2. Частичное хранилище (subdir) извлечение/регистрация. Mercurial и bzr не поддерживают это, а поддержка git ограничена. Это плохо в командной среде, но бесценно, если я хочу проверить что-то на другом компьютере из моего домашнего каталога.

Просто мой опыт.

37
user154489

После дополнительных исследований и просмотра этой ссылки: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Некоторые выдержки ниже):

  • Это невероятно быстро. Ни один другой SCM, который я использовал, не мог идти в ногу с ним, и я использовал много, включая Subversion, Perforce, darcs, BitKeeper, ClearCase и CVS.
  • Это полностью распространено. Владелец хранилища не может диктовать, как я работаю. Я могу создавать ветки и фиксировать изменения, пока они отключены на моем ноутбуке, а затем синхронизировать их с любым количеством других репозиториев.
  • Синхронизация может происходить на многих носителях. Канал SSH, по HTTP через WebDAV, по FTP или путем отправки электронных писем с исправлениями, которые будут применены получателем сообщения. Центральный репозиторий не требуется, но может использоваться.
  • Филиалы даже дешевле, чем в Subversion. Создать ветку так же просто, как записать 41-байтовый файл на диск. Удалить ветку так же просто, как удалить этот файл.
  • В отличие от Subversion ветки ведут свою полную историю. без необходимости выполнять странную копию и пройтись по копии. При использовании Subversion мне всегда было неловко смотреть историю файла на ветке, которая возникла до того, как была создана ветка. из #git: spearce: Я не понимаю одну вещь о SVN на странице. Я сделал ветку в SVN и просмотр истории показал всю историю файла в ветке
  • Слияние веток проще и более автоматическое в Git. В Subversion вам нужно помнить, с какой последней ревизии вы слились, чтобы вы могли сгенерировать правильную команду слияния. Git делает это автоматически и всегда делает это правильно. Это означает, что меньше шансов ошибиться при объединении двух веток.
  • Слияния ветвей записываются как часть правильной истории хранилища. Если я объединяю две ветви вместе или если я объединяю ветку обратно в ствол, из которого она получена, эта операция объединения записывается как часть истории репозитория как выполненная мной и когда. Трудно оспорить, кто выполнил слияние, когда оно прямо там в журнале.
  • Создание репозитория является тривиальной операцией: mkdir foo; cd foo; git init Вот и все. Что означает, что я создаю Git-репозиторий для всего, что в наши дни. Я склонен использовать один репозиторий на класс. Большинство этих репозиториев имеют размер менее 1 МБ на диске, поскольку в них хранятся только конспекты лекций, домашние задания и мои ответы на LaTeX.
  • Внутренние форматы хранилища невероятно просты. Это означает, что ремонт очень прост, но даже лучше, потому что он настолько прост, что его очень сложно испортить. Я не думаю, что кто-либо когда-либо имел поврежденный репозиторий Git. Я видел, как Subversion с fsfs испортилась сама. И я видел, как Berkley DB слишком часто портил себя, чтобы доверять мой код бэкэнду bdb в Subversion.
  • Формат файлов Git очень хорош для сжатия данных, несмотря на то, что это очень простой формат. Репозиторий CVS проекта Mozilla составляет около 3 ГБ; это около 12 ГБ в формате fsfs Subversion. В Git это около 300 МБ.

Прочитав все это, я убежден, что Git - это путь (хотя есть небольшая кривая обучения). Я также использовал Git и SVN на платформах Windows.

Я хотел бы услышать, что другие скажут после прочтения вышеизложенного?

24
Waqar

Я бы создал хранилище Subversion. Делая это таким образом, отдельные разработчики могут выбирать, использовать ли клиенты Subversion или Git-клиенты (с git-svn). Использование git-svn не дает вам всех преимуществ полноценного решения Git, но дает отдельным разработчикам большой контроль над своим рабочим процессом.

Я полагаю, что через некоторое время Git будет работать так же хорошо в Windows, как и в Unix и Mac OS X (как вы и просили).

Subversion имеет отличные инструменты для Windows, такие как интеграция TortoiseSVN для Explorer и интеграция AnkhSVN для Visual Studio.

11
Greg Hewgill

Самое смешное: я размещаю проекты в Subversion Repos, но получаю к ним доступ через команду Git Clone.

Пожалуйста, прочитайте Разработка с Git на Google Code Project

Хотя Google Code изначально говорит на Subversion, вы можете легко использовать Git во время разработки. Поиск "git svn" предполагает, что эта практика широко распространена, и мы также рекомендуем вам поэкспериментировать с ней.

Использование Git в репозитории Svn дает мне следующие преимущества:

  1. Я могу работать распределенным на нескольких машинах, совершая и извлекая их
  2. У меня есть центральный backup/public svn репозиторий для других, чтобы проверить
  3. И они могут свободно использовать Git для своих
11
Andre Bossard

Определенно svn, поскольку Windows - в лучшем случае - гражданин второго сорта в мире git (см. http://en.wikipedia.org/wiki/Git_ (software) #Portability для получения более подробной информации ).

ОБНОВЛЕНИЕ: Извините за неработающую ссылку, но я прекратил попытки заставить SO работать с URI, которые содержат круглые скобки. [ссылка исправлена ​​сейчас. -ed]

9
Hank Gay

Если ваша команда уже знакома с программным обеспечением для управления версиями и исходным кодом, таким как cvs или svn, то для простого и небольшого проекта (такого, как вы утверждаете), я бы порекомендовал вам придерживаться SVN. Я действительно доволен svn, но для текущего проекта электронной коммерции, который я делаю на Django, я решил работать с git (я использую git в svn-mode, то есть с централизованным репо, к которому я подталкиваю и извлекаю от того, чтобы сотрудничать по крайней мере с одним другим разработчиком). Другому разработчику удобно работать с SVN, и, хотя опыт других может отличаться, нам обоим действительно не хватает времени, чтобы использовать git для этого небольшого проекта. (Мы оба хардкорные пользователи Linux, если это вообще имеет значение.)

Ваш пробег может меняться, конечно.

9
ayaz

Не совсем отвечаю на ваш вопрос, но если вы хотите воспользоваться преимуществами Distributed Revision Control - звучит так, как будто вы - и вы используете Windows, я думаю, вам лучше использовать Mercurial скорее Git as Mercurial гораздо лучше поддерживает Windows. Mercurial также имеет порт Mac.

9
Dave Webb

Главное, что Git - это распределенная VCS, а Subversion - централизованная. Распределенные VCS немного сложнее для понимания, но имеют много преимуществ. Если вам не нужны эти преимущества, Subversion может быть лучшим выбором.

Другой вопрос - поддержка инструментов. Какие VCS лучше поддерживаются инструментами, которые вы планируете использовать?

РЕДАКТИРОВАТЬ: Три года назад я ответил так:

А на данный момент Git работает на Windows только через Cygwin или MSYS . Subversion поддерживала Windows с самого начала. Поскольку git-решения для окон могут работать на вас, могут возникнуть проблемы, так как большинство разработчиков Git работают с Linux и не думали о переносимости с самого начала. На данный момент я бы предпочел Subversion для разработки под Windows. Через несколько лет это может быть неактуально.

Теперь мир немного изменился. У Git хорошая реализация для Windows. Хотя я не проводил тщательного тестирования на Windows (поскольку я больше не использую эту систему), я вполне уверен, что все основные VCS (SVN, Git, Mercurial, Bazaar) теперь имеют надлежащую реализацию Windows. Это преимущество для SVN исчезло. Остальные пункты (Централизованные и Распределенные и проверка поддержки инструмента) остаются в силе.

8
Mnementh

Я бы выбрал SVN, так как он более распространен и известен.

Я думаю, Git будет лучше для пользователя Linux.

6
Burkhard

Это сводится к этому:

Будет ли ваше развитие линейным? Если это так, вы должны придерживаться Subversion.

Если, с другой стороны, ваша разработка не будет линейной, а это значит, что вам нужно будет создать ветвление для различных изменений, а затем объединить такие изменения с основной линией разработки (известной Git как основная ветвь), тогда Git сделает Гораздо больше для вас.

4
seedg

Я использовал SVN в течение долгого времени, но всякий раз, когда я использовал Git, я чувствовал, что Git является очень мощным, легким и хотя и требует немного обучения, но лучше, чем SVN.

Что я заметил, так это то, что каждый SVN-проект по мере роста становится очень большим по размеру, если только он не экспортируется. Где, как, проект GIT (вместе с данными Git) очень легкий по размеру.

В SVN я имел дело с разработчиками от новичка до эксперта, и новички и промежуточные пользователи, похоже, создают конфликты файлов, если они копируют одну папку из другого проекта SVN для ее повторного использования. Принимая во внимание, что я думаю, что в Git вы просто копируете папку, и она работает, потому что Git не представляет папки .git во всех своих подпапках (как это делает SVN).

После долгого общения с SVN я наконец-то решил переместить меня и моих разработчиков в Git, поскольку легко объединять и объединять работу, а также одним большим преимуществом является то, что изменения локальной копии могут быть зафиксированы настолько, насколько это возможно. желаемый, а затем, наконец, за один раз отправляется в ветку на сервере, в отличие от SVN (где мы должны время от времени фиксировать изменения в хранилище на сервере).

Кто-нибудь, кто может помочь мне решить, должен ли я действительно пойти с Git?

4
Waqar

Git изначально не поддерживается в Windows, только пока. Оптимизирован для систем Posix. Однако запуск Cygwin или MinGW позволяет вам успешно запустить Git.

В настоящее время я предпочитаю Git, а не SVN, но для того, чтобы преодолеть порог, если вы приехали из CVS, SVN, потребуется время.

4
Jonix

Я бы, наверное, выбрал Git, потому что чувствую, что он намного мощнее, чем SVN. Доступны дешевые услуги Code Hosting, которые отлично работают для меня - вам не нужно делать резервные копии или выполнять какие-либо работы по техническому обслуживанию - GitHub является наиболее очевидным кандидатом.

Тем не менее, я ничего не знаю об интеграции Visual Studio и различных систем SCM. Я представляю интеграцию с SVN заметно лучше.

4
Christoph Schiessl

На YouTube есть интересное видео об этом. Это от самого Линуса Торвальдса: Google Tech Talk: Линус Торвальдс на git

3
Roman Ganz

Могу ли я расширить этот вопрос и спросить, хорошо ли работает Git на MacOS?

Ответ на комментарии: Спасибо за новость, я с нетерпением ждал возможности попробовать это. Я установлю это дома на моем Mac.

3
Robert Gould

ты пробовал Bzr ?

Это довольно хорошо, connonical (люди, которые делают Ubuntu) сделали это, потому что им больше ничего не нравилось на рынке ...

3
Omar Kooheji

SVN кажется хорошим выбором под Windows, на что указывают другие люди.

Если кто-то из ваших разработчиков хочет попробовать GIT, он всегда может использовать GIT-SVN, где репозиторий SVN воссоздается в репозитории GIT. Затем он должен иметь возможность работать локально с GIT, а затем использовать SVN для публикации его изменений в основном хранилище.

2
Pierre

Вы должны пойти с DVCS, это как квантовый скачок в управлении источниками. Лично я использую Monotone и его время разработки не заканчивается. Мы используем его для Windows, Linux и Mac, и он был очень стабильным. У меня даже есть buildbot, выполняющий ночные сборки проекта на каждой из платформ.

Распространение DVCS обычно означает, что вы создадите центральный сервер, чтобы люди могли отправлять изменения в и из.

1
Phil Hannent