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

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

Ответы

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

Только мои переживания.

Ответ 5

После проведения дополнительных исследований и просмотра этой ссылки: 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 мне всегда было неудобно смотреть на историю файла на ветке, которая произошла до того, как была создана ветка. from # 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 ГБ в формате Subversion fsfs. В Git он составляет около 300 МБ.

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

  • Я могу работать на нескольких машины, совершающие и тянущие и к ним
  • У меня есть центральный репозиторий svn backup/public для других, чтобы проверить
  • И они могут свободно использовать Git для своих

Ответ 8

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

UPDATE: Извините за неработающую ссылку, но я отказался от попытки заставить SO работать с URI, содержащими круглые скобки. [ссылка исправлена. -ed]

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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

EDIT: Три года назад я ответил так:

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

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

Ответ 13

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

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

Ответ 14

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

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

Ответ 15

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

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

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

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

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

Ответ 16

Это сводится к следующему:

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

Если, с другой стороны, ваша разработка не будет линейной, а это означает, что вам нужно будет создать ветвление для разных изменений, а затем слияние таких изменений обратно в основную линию разработки (известную как Git как ведущая ветвь), то Git сделает БОЛЬШЕ больше для вас.

Ответ 17

Можно ли расширить вопрос и спросить, работает ли Git на MacOS?

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

Ответ 18

Вы пробовали Bzr?

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

Ответ 20

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

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

Ответ 21

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

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