Почему Git лучше, чем Subversion?

Я использую Subversion в течение нескольких лет, и после использования SourceSafe , я просто люблю Subversion. В сочетании с TortoiseSVN я не могу себе представить, как это может быть лучше.

Тем не менее, растет число разработчиков, утверждающих, что у Subversion есть проблемы и что мы должны перейти к новому поколению распределенных систем контроля версий, таких как Git .

Как Git улучшается после Subversion?

393 gitsvn
3.08.2008 22:38:29
30 ОТВЕТОВ
РЕШЕНИЕ

Git не лучше чем Subversion. Но тоже не хуже. Это другое.

Главное отличие в том, что он децентрализован. Представьте, что вы разработчик в дороге, вы разрабатываете на своем ноутбуке и хотите иметь контроль над исходным кодом, чтобы вы могли вернуться назад на 3 часа.

С Subversion у вас есть проблема: репозиторий SVN может находиться в месте, куда вы не можете попасть (в вашей компании, и у вас нет интернета в данный момент), вы не можете выполнить коммит. Если вы хотите сделать копию своего кода, вы должны буквально скопировать / вставить его.

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

Поначалу это выглядит хорошо, но имейте в виду сложность этого подхода.

Git, кажется, "новая, блестящая, классная" вещь. Это ни в коем случае не плохо (есть причина, по которой Линус написал это для разработки ядра Linux в конце концов), но я чувствую, что многие люди прыгают на поезд «Распределенный контроль исходного кода» только потому, что он новый и написан Линусом Торвальдсом, на самом деле без зная, почему / если это лучше.

У Subversion есть проблемы, но есть и у Git, Mercurial, CVS, TFS и так далее.

Изменить: Итак, этому ответу уже год, и он все еще вызывает много голосов, поэтому я подумал, что добавлю еще несколько объяснений. За последний год, прошедший с момента написания этой статьи, Git получил большой импульс и поддержку, особенно с тех пор, как такие сайты, как GitHub, действительно завоевали популярность. В настоящее время я использую Git и Subversion, и я хотел бы поделиться некоторыми личными соображениями.

Во-первых, Git может быть очень запутанным, когда работает децентрализованно. Что такое пульт? и как правильно настроить начальный репозиторий? это два вопроса, которые возникают в начале, особенно по сравнению с простым SVN "create svnadmin create", Git "git init" Git может принимать параметры --bare и --shared, что кажется "правильным" способом установки централизованного репозиторий. Есть причины для этого, но это добавляет сложности. Документация по команде «checkout» очень запутывает людей, переходящих на другую тему: «правильный» путь - это «git clone», а «git checkout», похоже, переключает ветки.

Git действительно светит, когда вы децентрализованы. У меня есть сервер дома и ноутбук в дороге, а SVN здесь просто не работает. С SVN у меня не может быть локального управления исходным кодом, если я не подключен к репозиторию (да, я знаю о SVK или о способах копирования репо). В любом случае, с Git это режим по умолчанию. Это дополнительная команда (git commit фиксирует локально, тогда как git push origin master передает ветку master на удаленный узел с именем "origin").

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

Кроме того, инструментов все еще недостаточно, по крайней мере, в Windows. Да, есть надстройка Visual Studio, но я все еще использую git bash с msysgit.

Преимущество SVN в том, что его НАМНОГО проще изучать: там есть ваш репозиторий, все изменения к нему, если вы знаете, как создавать, фиксировать и извлекать, и вы готовы к работе, а позже можете собирать такие вещи, как ветвление, обновление и т. Д. на.

Git имеет то преимущество, что он НАМНОГО лучше подходит, если некоторые разработчики не всегда подключены к главному репозиторию. Кроме того, это намного быстрее, чем SVN. И из того, что я слышал, поддержка ветвления и слияния намного лучше (что и следовало ожидать, так как это основные причины, по которым она была написана).

Это также объясняет, почему он так популярен в Интернете, поскольку Git идеально подходит для проектов с открытым исходным кодом: просто создайте его, передайте изменения в свой собственный Fork, а затем попросите оригинального сопровождающего проекта вытащить ваши изменения. С Git это просто работает. Действительно, попробуйте это на Github, это волшебство.

Я также вижу мосты Git-SVN: центральным репозиторием является репозиторий Subversion, но разработчики локально работают с Git, а затем мост вносит свои изменения в SVN.

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

548
28.12.2009 04:45:25
А Ferrari не лучше, чем Hyundai. Но тоже не хуже. Это другое. (Что? Не смотри на меня так ... Я что-то сказал не так?)
F.D.Castel 19.01.2009 03:13:13
Нет, ты не сделал. Ferrari - это непрактично, дорого, хочется пить, и вы не добьетесь лучшего от А до В, если будете жить в таком городе, как Нью-Йорк или Париж - я бы предпочел Hyundai для многих мест, в том числе потому, что царапина гораздо менее серьезна. Но каждому свое - у Ferrari тоже есть (очень мало) преимуществ ...
Michael Stum♦ 19.01.2009 07:29:47
Распределение - не единственная разница между Subversion и Git. Это также не добавляет сложности, если вы не используете несколько репозиториев. Есть много преимуществ использования Git вместо Subversion, но только несколько (в основном незначительных) недостатков. Git используется, потому что это хорошо, а не блестит.
sebnow 11.02.2009 05:40:07
Мой опыт работы с git не совсем «откровение, меняющее жизнь». Я считаю, что это отличный инструмент, когда он работает, когда, когда это не так, он чувствует себя довольно неполным. Меня не слишком впечатлили такие вещи, как вопрос 1052882, и хотя это явно проблема RTFM: я считаю, что git (и любые другие распределенные vcs) более сложны, чем централизованные, и я хотел бы рассмотреть возможность его использования в централизованных средах. , Но опять же, я в основном разработчик Windows, и инструменты для Windows все еще незрелые по сравнению с SVN.
Michael Stum♦ 7.08.2009 15:30:09
Вы только анализируете аспект распределения в сравнении. Я скажу тебе почему. Потому что вы хотите поделиться только кодом. Git и SVN - это нечто большее, вы когда-нибудь отмечали, разветвляли, объединяли, разрешали конфликты, копировали патчи между ветками? Я думаю, что ваш анализ просто ошибочен. В этих аспектах, Git очень мощный инструмент. Не говоря уже о вещах, которые может делать git, а SVN не может, таких как раздавливание, расчленение, внесение поправок, перебазирование, сбор вишни и многое другое.
mschonaker 6.10.2010 14:04:23

С Git вы можете делать практически все в автономном режиме, потому что у каждого есть свой собственный репозиторий.

Создание веток и слияние веток действительно легко.

Даже если у вас нет прав на коммит для проекта, вы все равно можете иметь свой собственный репозиторий в сети и публиковать «push-запросы» для своих патчей. Все, кому нравятся ваши патчи, могут включить их в свой проект, включая официальных сопровождающих.

Тривиально спроектировать проект, изменить его и продолжать объединять исправления ошибок из ветки HEAD.

Git работает для разработчиков ядра Linux. Это означает, что это действительно быстро (это должно быть), и масштабируется до тысяч участников. Git также использует меньше места (до 30 раз меньше места для хранилища Mozilla).

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

Наконец, есть GitHub , отличный сайт для размещения ваших Git-репозиториев.

Недостатки Git:

  • его гораздо сложнее освоить, потому что в Git больше понятий и больше команд.
  • ревизии не имеют номеров версий, как в Subversion
  • многие команды Git являются загадочными, а сообщения об ошибках очень недружественными для пользователя
  • ему не хватает хорошего графического интерфейса (такого как отличный TortoiseSVN )
145
27.07.2010 08:43:52
Хотя изучение всего Git будет намного сложнее, основы почти идентичны. Объем обучения не так уж и велик, пока вы не разберетесь с более продвинутыми вещами, на которые SVN в любом случае просто не способен.
sebnow 12.02.2009 10:31:14
+1 для меня. Я думаю, что многие разработчики забывают, что git не хватает чего-то вроде TortoiseSVN, и что не только разработчики используют контроль версий. Я вздрагиваю при мысли о необходимости объяснить (и поддержать) управление распределенной версией нашим не разработчикам, использующим SVN | TortoiseSVN!
si618 23.03.2009 16:42:47
Еще один недостаток - у вас должна быть полная копия репозитория, вы не можете работать с частичными файлами (что важно, если у вас есть огромные, как у многих корпораций)
gbjbaanb 7.08.2009 15:09:46
Я люблю мерзавца, но мне потребовалось около шести месяцев ежедневного использования, чтобы действительно эффективно его использовать. При этом я использую комбинацию оболочки git (командной строки) из msysgit, git gui и gitk из msysgit и TortoiseGit. Я думаю, что TortoiseGit великолепен, но я не понимаю, почему больше людей не используют его. Я знаю, что сопровождающие msysgit ненавидят TortoiseGit по разным причинам, некоторые из них идеологические, и это может быть как-то связано с этим. TortoiseGit - это хорошо сохранившийся секрет!
Jim Raden 7.08.2009 19:59:17
Я согласен. Я использую как SVN, так и GIT (примерно с 6 месяцев). Я, честно говоря, люблю мерзавцев намного больше, чем когда-либо делал SVN. Просто нужно время, чтобы выучить это. Самый большой скачок для меня (момент, когда я увидел свет: P) произошел, когда я наконец понял, что должен прекратить попытки использовать GIT так, как работает SVN. Тогда все стало на свои места;)
Blizz 24.07.2010 09:23:12

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

  1. Git имеет команду «clean». SVN остро нуждается в этой команде, учитывая, как часто она будет выгружать дополнительные файлы на ваш диск.
  2. Git имеет команду «пополам». Мило.
  3. SVN создает каталоги .svn в каждой папке (Git создает только один каталог .git). Каждый сценарий, который вы пишете, и каждый grep, который вы делаете, должны быть написаны, чтобы игнорировать эти каталоги .svn. Вам также нужна целая команда ("svn export") только для того, чтобы получить разумную копию ваших файлов.
  4. В SVN каждый файл и папка могут быть из разных ревизий или ветвей. Поначалу звучит приятно иметь такую ​​свободу. Но на самом деле это означает, что существует миллион различных способов, которыми ваша локальная касса будет полностью облажана. (например, если «svn switch» не работает в середине или если вы ввели команду неправильно). И самое худшее: если вы когда-нибудь попадете в ситуацию, когда некоторые из ваших файлов приходят из одного места, а некоторые из другого, «svn status» скажет вам, что все нормально. Вам нужно будет выполнить команду «svn info» для каждого файла / каталога, чтобы выяснить, насколько странны вещи. Если «git status» говорит вам, что все нормально, тогда вы можете верить, что все нормально.
  5. Вы должны сообщать SVN всякий раз, когда вы перемещаете или удаляете что-то. Git просто поймет это.
  6. Игнорировать семантику проще в Git. Если вы игнорируете шаблон (например, * .pyc), он будет игнорироваться для всех подкаталогов. (Но если вы действительно хотите что-то игнорировать только для одного каталога, вы можете это сделать). С SVN кажется, что нет простого способа игнорировать шаблон во всех подкаталогах.
  7. Еще один пункт, включающий игнорирование файлов. Git позволяет использовать «приватные» настройки игнорирования (используя файл .git / info / exclude), которые больше ни на кого не влияют.
110
31.01.2009 21:24:12
Объявление. 7. В современном git вы также можете настроить индивидуальное игнорирование для каждого пользователя, используя переменную конфигурации core.excludeFile в ~ .gitignore (см. Man git-config).
Jakub Narębski 23.02.2009 10:41:20
Re # 5: Хотя это обычно так, иногда Git все испортил. По крайней мере, в Subversion проблемы, связанные с перемещением или удалением, почти всегда являются PEBKAC. Хотя было бы полезно иметь автоматическое отслеживание перемещения / удаления, я все же по крайней мере буду благодарен за возможность явно указать, что я делаю с файлами в хранилище, даже если мне не нужно его использовать.
Chris Charabaruk 28.08.2009 00:17:26
@ Крис: Вы можете сделать это явно: git mvи git rm.
R. Martinho Fernandes 10.09.2009 10:57:48
Я также хотел бы видеть вариант одиночного каталога .svn для каждой рабочей копии, но для записи: Для # 3: Большинство инструментов (по умолчанию) игнорируют каталоги .svn. Для # 6: Вы можете установить свойства рекурсивно.
si618 13.10.2009 06:05:25
3: каталог «один .svn» будет здесь с SVN 1.7, когда будет реализован WC-NG. 1: Чтобы очистить SVN, вы «экспортируете» поверх своего туалета. 5: это не так просто, если вы переименуете файл, git распознает его и сохранит историю, или обработает его как добавление и удаление в каталоге ?. 6/7: svn имеет глобальное игнорирование для каждого пользовательского параметра клиента.
gbjbaanb 15.10.2009 21:25:01

« Почему Git лучше, чем X » описывает различные плюсы и минусы Git против других SCM.

Кратко:

  • Git отслеживает контент, а не файлы
  • Ветви легки , и объединение легко , и я имею в виду действительно легко .
  • Он распространяется, в основном каждый репозиторий является веткой. По моему мнению, намного проще разрабатывать одновременно и совместно, чем с Subversion. Это также делает возможной автономную разработку.
  • Это не навязывает какой-либо рабочий процесс , как видно на вышеупомянутом связанном веб-сайте , с Git возможно множество рабочих процессов. Рабочий процесс в стиле Subversion легко имитируется.
  • Репозитории Git намного меньше по размеру файла, чем репозитории Subversion. Существует только один каталог ".git", в отличие от десятков репозиториев ".svn" (обратите внимание, что Subversion 1.7 и выше теперь использует один каталог, такой как Git.)
  • Постановка область является удивительной, это позволяет видеть изменения , которые вы совершите, совершить частичные изменения и делать различные другие вещи.
  • Шкатулка неоценима, когда вы занимаетесь «хаотичной» разработкой или просто хотите исправить ошибку, пока вы еще работаете над чем-то другим (в другой ветке).
  • Вы можете переписать историю , которая отлично подходит для подготовки наборов патчей и исправления ваших ошибок ( перед публикацией коммитов)
  • ... и многое другое.

Есть некоторые недостатки:

  • Для этого пока не так много хороших графических интерфейсов. Он новый, и Subversion существует намного дольше, поэтому это естественно, поскольку в разработке есть несколько интерфейсов. Некоторые хорошие включают TortoiseGit и GitHub для Mac .
  • Частичные проверки / клоны репозиториев на данный момент невозможны (я читал, что это в разработке). Тем не менее, есть поддержка субмодулей. Git 1.7+ поддерживает редкие проверки .
  • Это может быть труднее учиться, хотя я не считаю, что это так (около года назад). Git недавно улучшил свой интерфейс и довольно удобен для пользователя.

В наиболее простом использовании Subversion и Git практически одинаковы. Там нет большой разницы между:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

и

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Где Git действительно сияет, так это ветвление и работа с другими людьми.

56
25.10.2011 06:30:09
Вы говорите, что GIT отслеживает контент, а не файлы. Я обнаружил, что SVN также делает это: я просто внес изменения в файл и сохранил его. SVN показал файл как красный (изменено). Затем я отменил в редакторе и сохранил его снова. Затем SVN обновил статус до зеленого (не изменился), даже если файл был изменен (дата изменения более новая), но SVN обнаружил, что содержимое не изменилось с исходного.
awe 7.10.2009 08:35:13
SVN отслеживает изменения по файлам?
Seun Osewa 3.03.2010 23:55:53
@ Awe, это называется отслеживание файлов. попробуйте переименовать файл или переместить его в другое место вручную [тот же контент, новый файл (из-за нового пути / имени)): узнает ли SVN, что это тот же файл, и сохранит предыдущие бесчисленные изменения, которые вы сделали в нем? нет, наверное нет.
Filip Dupanović 18.05.2010 21:07:27
TortoiseGit - code.google.com/p/tortoisegit | Git 1.7 разреженных извлечений - kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt
Zaz 19.08.2010 10:45:23

Google Tech Talk: Линус Торвальдс на Git

http://www.youtube.com/watch?v=4XpnKHJAok8

Страница сравнения Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion

54
3.08.2008 22:44:26
Говорить с Линусом интересно. Он жестоко разрывает централизованные системы контроля версий, такие как Subversion и CVS. Тем не менее, разговор Рэндала Шварца с youtube.com/watch?v=8dhZ9BXQgc4 более конструктивный, более информативный и более убедительный.
bendin 10.11.2008 07:44:29
Это тоже довольно мило. Это от одного из коммиттеров git, и он объясняет множество продвинутых функций, таких как разбиение больших коммитов на более мелкие. youtube.com/watch?v=j45cs5_nY2k
schoetbi 23.09.2010 18:22:36
Мне очень нравится это видео Линуса Торвальдса, но он подразумевает, что git распространяется, а не централизовано, и это просто неправильно. Он может использоваться распределенным образом, ИЛИ централизованным образом. Вы можете иметь один центральный репозиторий, к которому все обязуются, как в SVN. Просто вам не нужно делать это таким образом.
MatrixFrog 1.12.2010 08:53:49
@MatrixForog: я думаю, что в этом случае «децентрализованный» не является противоположностью «централизованного», а действительно надмножество. Это как «мобильный» и «неподвижный» - только потому, что что-то «мобильное», я не могу стоять на месте.
Tikhon Jelvis 29.05.2011 17:56:28

Ну, это распространяется. Тесты показывают, что он значительно быстрее (учитывая его распределенную природу, такие операции, как diff и logs, все локальные, поэтому, конечно, в этом случае он работает невероятно быстро), а рабочие папки меньше (что все еще поражает воображение).

Когда вы работаете над Subversion или любой другой клиент-серверной системой контроля версий, вы по сути создаете рабочие копии на своем компьютере, проверяя версии. Это представляет собой моментальный снимок того, как выглядит хранилище. Вы обновляете свою рабочую копию с помощью обновлений, а вы обновляете хранилище с помощью коммитов.

С распределенным управлением версиями у вас нет снимка, а всего кода. Хотите сделать различие с 3-месячной версией? Нет проблем, 3-месячная версия все еще на вашем компьютере. Это не только означает, что дела идут намного быстрее, но если вы отключены от центрального сервера, вы все равно можете выполнять многие операции, к которым вы привыкли. Другими словами, у вас есть не только снимок данной ревизии, но и всего кода.

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

26
13.10.2008 19:13:34
Причина, по которой Git может занять меньше места на диске для полного хранилища, чем Subversion для простой проверки, заключается в том, что Subversion хранит «нетронутую копию», чтобы заставить 'svn diff' (сравнение с последней версией) работать ... и что хранилище git сжимается (и дельтацируется) ).
Jakub Narębski 11.02.2009 14:58:38
Я не удивлен, что git «рабочие папки» (т.е. репозитории) меньше рабочих копий svn, потому что даже репозитории svn меньше рабочих копий svn.
R. Martinho Fernandes 10.09.2009 11:02:25

Основные моменты, которые мне нравятся в DVCS:

  1. Вы можете совершать разбитые вещи. Это не имеет значения, потому что другие люди не увидят их, пока вы не опубликуете. Время публикации отличается от времени коммита.
  2. Из-за этого вы можете совершать чаще.
  3. Вы можете объединить полную функциональность. Эта функциональность будет иметь свою ветвь. Все коммиты этой ветки будут связаны с этой функциональностью. Вы можете сделать это с CVCS, однако с DVCS это по умолчанию.
  4. Вы можете искать свою историю (найти, когда функция изменилась)
  5. Вы можете отменить извлечение, если кто-то испортит основной репозиторий, вам не нужно исправлять ошибки. Просто очистите слияние.
  6. Когда вам нужен контроль исходного кода в любом каталоге, выполните: git init. и вы можете совершать, отменять изменения и т.д ...
  7. Это быстро (даже на Windows)

Основная причина относительно большого проекта - улучшенная коммуникация, созданная пунктом 3. Другие - приятные бонусы.

22
1.12.2010 08:57:19
Я думаю, что пункт № 1 намеревается сказать, что «другие люди не увидят их, пока вы не опубликуете » (или «нажмите»).
jackr 22.11.2010 18:52:51
+1 "Ты можешь совершать разбитые вещи." является основной причиной, почему я рассматриваю переход на git с SVN. Я всегда ненавижу, когда я на полпути разработки тяжелого блока кода, и у меня нет системы безопасности VCS (просто потому, что мои модификации еще не работают, поэтому я не могу коммитить).
András Szepesházi 4.05.2011 09:38:13

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

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

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

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

  1. Я могу работать распределенным на нескольких машинах, совершая и вытягивая их
  2. У меня есть центральный backup/public репозиторий SVN для других, чтобы проверить
  3. И они могут свободно использовать Git для своих
15
2.10.2008 13:05:58
это немного устарело, код Google делает Mercurial, так что больше не нужно для этого взлома
Sam Saffron 11.01.2010 10:32:52
@ Сам, если тебе не нравится мерзавец и / или не нравится ртутный.
MatrixFrog 1.12.2010 08:58:10

Все ответы здесь, как и ожидалось, ориентированы на программиста, однако что произойдет, если ваша компания использует контроль версий за пределами исходного кода? Есть много документов, которые не являются исходным кодом, которые выигрывают от контроля версий, и должны жить рядом с кодом, а не в другой CMS. Большинство программистов не работают изолированно - мы работаем для компаний как часть команды.

Имея это в виду, сравните простоту использования, как в инструментах клиента, так и в обучении, между Subversion и git. Я не вижу сценария, когда какую-либо распределенную систему контроля версий будет проще использовать или объяснить непрограммисту. Мне бы очень хотелось оказаться ошибочным, потому что тогда я смогу оценить git и действительно иметь надежду, что его примут люди, которым нужен контроль версий, но не программисты.

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

Отказ от ответственности: я заинтересовался Subversion на ранних стадиях (около v0.29), так что, очевидно, я предвзят, но компании, в которых я работал с тех пор, извлекают выгоду из моего энтузиазма, потому что я поощрял и поддерживал его использование. Я подозреваю, что так происходит с большинством компаний-разработчиков программного обеспечения. Интересно, так как многие программисты используют платформу git, как многие компании будут упускать преимущества использования контроля версий вне исходного кода? Даже если у вас есть отдельные системы для разных групп, вы упускаете некоторые преимущества, такие как (унифицированная) интеграция с отслеживанием проблем, при одновременном повышении требований к обслуживанию, оборудованию и обучению.

11
15.03.2010 23:38:20
ИМХО, это единственная уважительная причина в пользу SVN. Короче говоря, это проще объяснить непрограммисту, то есть тому, кто рассчитывал использовать его линейно и избегать сложных (= реальных) сценариев VC: конфликты, трехсторонние слияния, ветвления .. Я имею в виду, вы бы никогда не позволяйте VCS объединить файл презентации PowerPoint ..
inger 27.07.2010 19:16:05
«Большинство программистов не работают изолированно», похоже, предполагает, что бухгалтерам / маркетологам придется использовать то же хранилище, где хранится исходный код. Я не вижу преимуществ этого; некоторые мои бывшие компании хотели стандартизировать подобные вещи, но это неизбежно провалилось. Я думаю, что упрощенный подход может быть полезен для менеджера, но слишком упрощен для команд программистов - поэтому их объединение ведет к плохому компромиссу.
inger 27.07.2010 19:22:49
Для документов, которые идут с программным обеспечением, вы правы - они должны быть версионированы вместе. Я обнаружил, что это гораздо меньше, чем думают люди вначале (в итоге мы выбросили огромное дерево документов из репо-источника). Кроме того, вы можете многое сделать для упрощения рабочих процессов технических писателей и т. Д., Если это будет проблемой (не должно).
inger 27.07.2010 19:31:03
@inger Я не думаю, что вы можете сказать «это единственная действительная причина», поддержка инструментов AFAIK для Subversion намного превосходит Git, например, TortoiseSVN и интеграцию с Visual Studio и Java IDE, такой как Eclipse. Возможно, это не проблема для вас, но, безусловно, для нас. Я не упомянул об этом в своем ответе, потому что это отдельная проблема.
si618 28.07.2010 00:56:18
@ Да, да, это правда, что непрограммистам понадобится время, чтобы получить Subversion, но я думаю, что они будут дольше с git или Hg. Вики хороши, если их поддерживают, но по моему опыту разработчики с большей вероятностью будут поддерживать документы, связанные с исходным кодом, если они близки к этому исходному коду. Я согласен с Йингером в том, что не так много документов, которые соответствуют этой категории, но они, безусловно, существуют. Интересно, вы говорите, что git / Hg - лучший инструмент для работы, это общее утверждение, которое, вероятно, не подходит для всех обстоятельств, имеет ли git и Hg такую ​​же хорошую интеграцию, как SVN?
si618 4.05.2011 06:08:55

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

9
23.05.2017 11:33:24
Но теперь, после интенсивного использования git в течение пары лет, я должен не согласиться с самим собой: Git намного лучше, чем Subversion. По крайней мере, когда вы преодолеете недружелюбный синтаксис Git.
neu242 20.09.2011 12:39:22

Одна из особенностей SubVersion, которая меня раздражает, заключается в том, что она помещает свою собственную папку в каждый каталог проекта, тогда как git помещает только одну в корневой каталог. Это не что большой сделки, но такие мелочи , как , что складывают.

Конечно, у SubVersion есть Turtoise, что [обычно] очень приятно.

8
22.08.2008 15:24:44
.svn dirs скоро исчезнет, ​​вероятно, с
gbjbaanb 7.08.2009 15:11:54

Дэвид Ричардс WANdisco Блог о Subversion / GIT

Появление GIT привело к порождению фундаменталистов DVCS - «Gitterons», которые думают, что все, кроме GIT, является дерьмом. Гиттероны, кажется, думают, что разработка программного обеспечения происходит на их собственном острове, и часто забывают, что большинство организаций не нанимают исключительно старших разработчиков программного обеспечения. Это нормально, но это не так, как думает остальная часть рынка, и я рад это доказать: у GIT, по последним данным, было менее трех процентов рынка, в то время как у Subversion было пять миллионов пользователей и около половины общий рынок.

Проблема, которую мы видели, состояла в том, что Гиттероны стреляли (дешевыми) выстрелами в Subversion. Твиты типа «Subversion такой [медленный / дрянной / ограничительный / плохо пахнет / смешно смотрит на меня], и теперь у меня есть GIT и [все работает в моей жизни / моя жена забеременела / у меня появилась девушка после 30 лет попыток / я шесть раз побеждал на столе в блэкджеке]. Вы получаете картину.

8
17.09.2010 18:22:30
Обратите внимание, что Дэвид Ричардс может быть беспристрастным: продукт, который он делает, основан на Subversion (или на идеях Subversion), поэтому, конечно, он будет за Subversion и против Git.
Jakub Narębski 20.09.2010 09:21:11
По иронии судьбы, Git был создан специально, потому что разработка программного обеспечения не происходит на островах. Эта цитата дебильная.
Ben Collins 25.01.2011 19:29:25
Хотя я использую git, я также был бы счастлив работать с любыми приличными DVCS, такими как, например, Mercurial. Понадобилось время, чтобы концепция DVCS приобрела популярность, и теперь я вижу, что огромное количество проектов с открытым исходным кодом перешли на git.
Keyo 3.05.2011 21:21:52
Рисуя противников svn фундаменталистами, Дэвид обошел фундаментальную проблему: архитектура подрывной деятельности - это тупик. Дело не в том, что git - это конечный продукт VCS, у него есть свои недостатки, но git, mercurial, darcs и многие другие VCS имеют принципиально более элегантные модели репозитория. Subversion никогда не заставит слияние работать, потому что модель каталогов == делает реальный прогресс невозможным. Такие компании, как David's, могут все больше и больше намазывать помаду на свинью, но svn неизбежно будет отставать все дальше и дальше от уровня техники.
gtd 25.05.2011 19:04:03

Git также упрощает ветвление и слияние. Subversion 1.5 только что добавил отслеживание слияний, но Git все еще лучше. С Git ветвление очень быстрое и дешевое. Это делает создание ветки для каждой новой функции более осуществимым. Репозитории Oh и Git очень эффективны с пространством хранения по сравнению с Subversion.

7
28.07.2010 18:30:37

Все дело в простоте использования / шагах, необходимых для того, чтобы что-то сделать.

Если я разрабатываю один проект на моем ПК / ноутбуке, лучше использовать git, потому что его гораздо проще настроить и использовать. Вам не нужен сервер, и вам не нужно продолжать вводить URL-адреса хранилища, когда вы делаете слияния.

Если бы это было всего 2 человека, я бы сказал, что git также проще, потому что вы можете просто толкать и тянуть друг друга.

Однако, как только вы выйдете за пределы этого, я пойду на подрывную деятельность, потому что в этот момент вам нужно настроить «выделенный» сервер или местоположение.

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

У SVN также есть преимущество более совершенных инструментов с графическим интерфейсом, однако экосистема git, похоже, быстро догоняет, поэтому я не буду беспокоиться об этом в долгосрочной перспективе.

6
3.08.2008 23:38:05
Отделение фиксации от публикации в Git является ИМХО преимуществом, а не недостатком.
Jakub Narębski 11.02.2009 14:59:55
Итак, как бы вы оценили «простоту использования / шаги, необходимые для чего-то» для SVN, когда: - создание тематической ветви для экспериментов - слияние этой ветви в другую ветку - разбиение отредактированного материала в файле на их собственные меньшие коммиты - быстро проверяя основную ветку, чтобы сделать небольшое исправление ИМХО Я не вижу, как проще настроить SVN-сервер, чем настроить ваш git-сервер. И почему вы хотите отказаться от всех приятных преимуществ, которые вы получаете от легких веток, просто чтобы вам не «приходилось раздвигать»?
Sam 30.09.2010 14:03:56
Аргумент «ветка темы для экспериментирования» часто выдвигается в пользу git, но, честно говоря, я никогда не видел, чтобы кто-то на самом деле делал это в subversion или другой системе, отличной от DVCS. Возможно, это большое дело, и мы все пропускаем, но из того, что я видел, 99% разработчиков (включая меня) не заботятся о ветвях тем, потому что они никогда не используют их! - Вы не можете пропустить то, что у вас никогда не было :-). Я думаю, что если люди из DVCS собираются выдвигать «тематические ветки» как функцию, они должны сначала убедить всех, что такие вещи действительно полезны.
Orion Edwards 30.09.2010 19:32:32
«Разделение отредактированного материала на более мелкие коммиты», опять же, звучит хорошо в теории. Но за последние 3 года я ни разу не подумал: «О, я бы хотел это сделать», и я изо всех сил пытаюсь даже придумать гипотетическую ситуацию, когда я мог бы захотеть эту особенность ... Большая часть мерзости Сторонники DVCS просто говорят: «У нас есть X, а X - это круто», а все остальные сидят и гадают, зачем им вообще нужен X
Orion Edwards 30.09.2010 19:36:36

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

6
22.08.2008 15:19:57

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

Мои собственные соображения также заставляют меня думать, что DVCS усложняет контроль качества и управление релизами, если вы делаете такие вещи, как централизованные релизы. Кто-то должен нести ответственность за выполнение этого push / pull из репозитория всех остальных, разрешение любых конфликтов, которые были бы разрешены при первоначальном времени фиксации ранее, затем выполнение сборки и затем повторную синхронизацию всех других разработчиков своих репозиториев.

Конечно, все это можно решить с помощью человеческих процессов; DVCS просто сломал что-то, что было исправлено централизованным контролем версий, чтобы обеспечить некоторые новые удобства.

5
3.08.2008 23:08:23
На самом деле, если вы выглядите так, как будто ядро ​​Linux или сам проект git управляются, вы увидите, что Git очень хорош для рабочего процесса «один сопровождающий» (или сопровождающий + лейтенанты) с одним центральным репозиторием консенсуса. И это позволяет легко переключаться на кого-то другого в качестве сопровождающего.
Jakub Narębski 23.02.2009 10:44:35

Мне нравится Git, потому что он на самом деле помогает коммуникационному разработчику разработчику в средней и большой команде. Как распределенная система контроля версий, благодаря своей системе push / pull она помогает разработчикам создавать экосистему исходного кода, которая помогает управлять большим количеством разработчиков, работающих над одним проектом.

Например, скажем, вы доверяете 5 разработчикам и извлекаете только коды из их репозитория. Каждый из этих разработчиков имеет свою собственную сеть доверия, откуда они извлекают коды. Таким образом, разработка основана на той структуре доверия разработчиков, в которой ответственность за код распределяется между сообществом разработчиков.

Конечно, есть и другие преимущества, которые упоминаются в других ответах здесь.

5
26.07.2010 08:52:15

Несколько ответов были упомянуты на них, но я хочу сделать два явных замечания:

1) Возможность делать выборочные коммиты (например, git add --patch). Если ваш рабочий каталог содержит несколько изменений, которые не являются частью одного и того же логического изменения, Git очень легко делает фиксацию, которая включает только часть изменений. С Subversion это сложно.

2) Способность совершать изменения без публикации изменений. В Subversion любой коммит является сразу общедоступным и, следовательно, безотзывным. Это сильно ограничивает способность разработчика «делать коммиты рано, часто».

Git - это больше, чем просто VCS; это также инструмент для разработки патчей. Subversion - это просто VCS.

4
24.07.2010 09:17:43
По поводу 1) Если вы используете TortoiseSVN, AnkhSVN и т. Д., То очень легко (тривиально) выбрать файлы с изменениями для фиксации. По поводу 2) Если вы не хотите, чтобы другие разработчики получали ваш код, создайте ветвь и затем объединитесь, когда будете готовы, это не сложно.
si618 9.04.2010 07:45:25
безотзывный? Что ж, вы можете выполнить обратное объединение ошибочного коммита и хранилище, как это было раньше. Но вы правы, это задокументировано. Но хорошо это или плохо? Я предполагаю, что это зависит ...
schoetbi 23.09.2010 18:31:41
@schoetbi Нет, глава хранилища такая же, как была раньше. Сам репозиторий теперь содержит два коммита, хотя было бы неплохо, если бы ни одного из них там не было. Это дополнительный беспорядок, который замедляет вас, когда вы просматриваете журналы. Конечно, это может случиться и с git, особенно если некоторые разработчики имеют привычку пушить сразу после коммита. Но это намного проще избежать в Git.
MatrixFrog 1.12.2010 09:06:55

Я думаю, что с Subversion все в порядке ... пока вы не начнете объединяться ... или делать что-то сложное ... или делать что-то, что Subversion считает сложным (например, выполнять запросы, чтобы выяснить, какие ветви связаны с конкретным файлом, откуда на самом деле происходят изменения , обнаруживать копии и вставки , и т.д)...

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

Просто он невероятно мощный, быстрый и, после привыкания к концепциям, очень полезный (да, в этом смысле: удобный для пользователя).

Для получения более подробной информации об истории слияния смотрите: Использование git-svn (или аналогичного) * просто *, чтобы помочь слиянием svn?

4
23.05.2017 11:47:36

Благодаря тому, что ему не нужно постоянно обмениваться данными с центральным сервером, практически каждая команда выполняется менее чем за секунду (очевидно, что git push / pull / fetch медленнее просто потому, что им нужно инициализировать соединения SSH). Ветвление намного проще (одна простая команда для ветвления, одна простая команда для объединения)

3
30.08.2008 12:01:09

Мне очень нравится, что я могу управлять локальными ветвями моего исходного кода в Git, не запутывая воду центрального хранилища. Во многих случаях я извлекаю код с сервера Subversion и запускаю локальный репозиторий Git, чтобы сделать это. Также замечательно, что инициализация Git-репозитория не загрязняет файловую систему кучей раздражающих папок .svn повсюду.

Что касается поддержки инструментов Windows, TortoiseGit отлично справляется с основами, но я все же предпочитаю командную строку, если не хочу просматривать журнал. Мне очень нравится, как Tortoise {Git | SVN} помогает при чтении логов коммитов.

3
22.07.2010 17:30:34

Это неправильный вопрос. Слишком легко сосредоточиться на бородавках git и сформулировать аргумент о том, почему subversion якобы лучше, по крайней мере, для некоторых случаев использования. Тот факт, что git изначально разрабатывался как низкоуровневый конструктор контроля версий и имеет интерфейс, ориентированный на разработчиков в стиле барокко, облегчает священным войнам набирать обороты и обретает легитимность. Сторонники Git бьют по барабану миллионами преимуществ рабочего процесса, которые svn ребята объявляют ненужными. Довольно скоро вся дискуссия становится централизованной и распределенной, что служит интересам сообщества разработчиков инструментальных средств для предприятий. Эти компании, которые обычно публикуют наиболее убедительные статьи о превосходстве Subversion на предприятии, зависят от ощущаемой небезопасности git и готовности svn на предприятии к долгосрочному успеху своих продуктов.

Но вот проблема: Subversion - это тупик архитектуры .

Принимая во внимание, что вы можете взять git и создать централизованную замену subversion довольно легко, несмотря на то, что svn работает вдвое больше, чем svn, и он никогда не мог заставить работать даже базовое отслеживание слияний так же близко, как в git. Одной из основных причин этого является проектное решение сделать ветви такими же, как каталоги. Я не знаю, почему они пошли так изначально, это, конечно, делает частичные проверки очень простыми. К сожалению, это также делает невозможным правильное отслеживание истории. Теперь очевидно, что вы должны использовать соглашения о компоновке хранилища Subversion для отделения веток от обычных каталогов, а svn использует некоторую эвристику, чтобы заставить вещи работать в повседневных случаях использования. Но все это просто наложение очень плохого и ограничивающего низкоуровневого проектного решения. Способность выполнять различие в хранилище (а не различие в каталогах) является основной и критической функциональностью для системы управления версиями и значительно упрощает внутреннее устройство, позволяя создавать более интеллектуальные и полезные функции поверх нее. Вы можете увидеть, сколько усилий было приложено к расширению Subversion, и тем не менее, насколько далеко он отстает от нынешнего урожая современных VCS с точки зрения фундаментальных операций, таких как разрешение слиянием.

Вот мой сердечный и агностический совет всем, кто все еще верит, что Subversion достаточно хороша в обозримом будущем:

Subversion никогда не догонит более новые породы VCS, которые извлекли уроки из ошибок RCS и CVS; это техническая невозможность, если они не переоснастят модель хранилища с нуля, но тогда это не будет svn, не так ли? Независимо от того, насколько вы думаете, что вы не обладаете возможностями современной VCS, ваше невежество не защитит вас от ловушек Subversion, многие из которых представляют собой ситуации, которые невозможно или легко разрешить в других системах.

Крайне редко техническая неполноценность решения настолько ясна, как и в svn, конечно, я бы никогда не высказал такого мнения о win-vs-linux или emacs-vs-vi, но в этом случае это так Ясно, что управление исходным кодом является настолько фундаментальным инструментом в арсенале разработчика, что я считаю, что это должно быть сформулировано однозначно. Независимо от требования использовать svn по организационным причинам, я умоляю всех пользователей svn не позволять их логическому уму создавать ложное убеждение, что более современные VCS полезны только для больших проектов с открытым исходным кодом. Независимо от характера вашей работы по разработке, если вы программист, вы будете более эффективным программистом, если узнаете, как использовать более качественные VCS, будь то Git, Mercurial, Darcs или многие другие.

3
29.05.2011 17:30:50

Subversion очень прост в использовании. В последние годы я никогда не обнаруживал проблем или того, что что-то работает не так, как ожидалось. Также есть много отличных инструментов с графическим интерфейсом и поддержка интеграции SVN.

С Git вы получаете более гибкий VCS. Вы можете использовать его так же, как SVN с удаленным репозиторием, где вы фиксируете все изменения. Но вы также можете использовать его в основном в автономном режиме и время от времени отправлять изменения только в удаленный репозиторий. Но Git более сложен и имеет более крутой курс обучения. Я впервые обнаружил, что совершаю неправильные ветки, косвенно создаю ветки или получаю сообщения об ошибках с небольшим количеством информации об ошибке и где я должен искать в Google, чтобы получить более качественную информацию. Некоторые простые вещи, такие как замена маркеров ($ Id $), не работают, но GIT имеет очень гибкий механизм фильтрации и подключения для объединения собственных сценариев, поэтому вы получаете все, что вам нужно, и больше, но для этого нужно больше времени и чтение документации. ;)

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

Git лучше чем SVN? Разработчики, которым нужна только некоторая история версий и механизм резервного копирования, хорошо и легко работают с SVN. Разработчики, часто работающие с ветками, тестирующие больше версий одновременно или работающие в основном в автономном режиме, могут воспользоваться функциями Git. Есть некоторые очень полезные функции, такие как тайник, которого нет в SVN, который может облегчить жизнь. Но с другой стороны не всем людям понадобятся все функции. Так что я не вижу мертвых SVN.

Git нужна лучшая документация, а отчеты об ошибках должны быть более полезными. Также существующие полезные графические интерфейсы встречаются редко. На этот раз я нашел только 1 графический интерфейс для Linux с поддержкой большинства функций Git (git-cola). Интеграция с Eclipse работает, но она официально не выпущена, и официального сайта обновлений нет (только некоторые внешние сайты обновлений с периодическими сборками из ствола http://www.jgit.org/updates ). Так что наиболее предпочтительный способ использования Git в эти дни это командная строка

2
13.10.2009 13:21:19

Эрик Синк из SourceGear написал серию статей о различиях между распределенными и нераспределенными системами контроля версий. Он сравнивает плюсы и минусы большинства популярных систем контроля версий. Очень интересное чтение.
Статьи можно найти в его блоге, www.ericsink.com :

2
6.08.2010 08:48:21

Для людей, которые ищут хороший графический интерфейс Git, Syntevo SmartGit может быть хорошим решением. Я считаю, что его проприетарное, но бесплатное для некоммерческого использования, работает на Windows / Mac / Linux и даже поддерживает SVN, используя какой-то мост git-svn.

2
9.03.2011 14:05:56

http://subversion.wandisco.com/component/content/article/1/40.html

Я думаю, что можно с уверенностью сказать, что среди разработчиков SVN Vs. Спор Git бушевал в течение некоторого времени, и каждый имеет свой взгляд на то, что лучше. Это было затронуто даже во время нашего вебинара по Subversion в 2010 году и далее.

Хайрам Райт, наш директор Open Source и президент Subversion Corporation, рассказывает о различиях между Subversion и Git, а также другими распределенными системами контроля версий (DVCS).

Он также рассказывает о предстоящих изменениях в Subversion, таких как Working Copy Next Generation (WC-NG), которые, по его мнению, заставят многих пользователей Git перейти обратно в Subversion.

Посмотрите его видео и дайте нам знать, что вы думаете, либо комментируя этот блог, либо размещая на наших форумах. Регистрация проста и займет всего минуту!

1
10.02.2010 18:51:32
Очевидно предвзятый, так как его инструмент основан на Subversion. Просто говорю.
Jakub Narębski 27.07.2010 18:12:38

Git в Windows довольно хорошо поддерживается сейчас.

Проверьте GitExtensions = http://code.google.com/p/gitextensions/

и руководство для лучшего опыта работы с Windows Git.

1
15.02.2010 14:24:29

В последнее время я живу на Git Land, и мне нравится это для личных проектов, но я пока не смогу переключать на него рабочие проекты с Subversion, учитывая изменение в мышлении, которое требуется от персонала, без каких-либо неотложных преимуществ. Более того, самый большой проект, который мы запускаем внутри компании, чрезвычайно зависит от svn: externals, который, из того, что я видел до сих пор, не очень хорошо и без проблем работает в Git.

1
21.07.2010 12:57:07

Во-первых, параллельное управление версиями кажется простой задачей для решения. Это совсем не так. Так или иначе...

SVN совершенно не интуитивно понятен. Мерзавец еще хуже. [sarcastic-speculation] Это может быть потому, что разработчики, которым нравятся сложные проблемы, такие как одновременный контроль версий, не очень заинтересованы в создании хорошего пользовательского интерфейса. [/ Саркастичное-предположение]

Сторонники SVN считают, что им не нужна распределенная система контроля версий. Я тоже так думал. Но теперь, когда мы используем исключительно Git, я верующий. Теперь у меня работает контроль версий И команда / проект, а не просто работа над проектом. Когда мне нужна ветка, я ветвлюсь. Иногда это ветвь с соответствующей ветвью на сервере, а иногда ее нет. Не говоря уже о всех других преимуществах, над которыми мне придется поработать (отчасти благодаря таинственному и абсурдному отсутствию пользовательского интерфейса, который является современной системой контроля версий).

1
22.07.2010 09:40:12

Почему я думаю, что Subversion лучше, чем Git (по крайней мере, для проектов, над которыми я работаю), в основном из-за его удобства использования и более простого рабочего процесса:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

1
22.10.2010 16:25:05