Что мне следует использовать - SVN или Git?

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

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

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

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

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

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

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

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

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

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

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

And Git works on Windows at the moment only via Cygwin or MSYS. Subversion supported Windows from the beginning. As the git-solutions for windows may work for you, there may be problems, as the most developers of Git work with Linux and didn't have portability in the mind from the beginning. At the moment I would prefer Subversion for development under Windows. In a few years this may be irrelevant.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VonC: You are confusing fundamental difference in implementation (the differences are very fundamental, we both clearly agree on this) with difference in purpose.
They are both tools used for the same purpose: this is why many teams who've formerly used SVN have quite successfully been able to dump it in favor of Git.
If they didn't solve the same problem, this substitutability wouldn't exist.

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

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

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

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

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

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

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

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

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

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

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

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

После дополнительных исследований и просмотра этой ссылки: 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 на странице. Я сделал ветку i 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.

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

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

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

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