Должен ли я использовать SVN или Git? [закрыто]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Частичное хранилище (subdir) извлечение / регистрация. Mercurial и bzr не поддерживают это, а поддержка 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 на странице. Я сделал ветку в 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. Делая это таким образом, отдельные разработчики могут выбирать, использовать ли клиенты Subversion или Git-клиенты (с git-svn). Использование git-svnне дает вам всех преимуществ полноценного решения Git, но дает отдельным разработчикам большой контроль над своим рабочим процессом.

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

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

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

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

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

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

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

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

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

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

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

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

Главное, что 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 исчезло. Остальные пункты (Централизованные и Распределенные и проверка поддержки инструмента) остаются в силе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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