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

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

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

Как Git улучшает Subversion?

Ответов (25)

Решение

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

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

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

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

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

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

У Subversion есть проблемы, как и у Git, Mercurial, CVS, TFS или чего-то еще.

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

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

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

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

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

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

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

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

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

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

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

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

В статье « Почему 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 [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создавать ветки и объединять ветки очень просто.

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

Разветвить проект, изменить его и по-прежнему вносить исправления из ветки HEAD - тривиально.

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

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

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

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

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

Все дело в простоте использования / необходимых действиях.

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

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

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

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

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

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

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

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

Главное, что мне нравится в DVCS:

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

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

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

  1. В Git есть «чистая» команда. SVN отчаянно нуждается в этой команде, учитывая, как часто он будет выгружать лишние файлы на ваш диск.
  2. В Git есть команда bisect. Мило.
  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), которые никому не повлияют.

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

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

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

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

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

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

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

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

В нескольких ответах на это упоминалось, но я хочу указать 2 явных момента:

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

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

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

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

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

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

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

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

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

With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn't work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation ;)

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

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

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

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

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

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

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

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

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

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

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

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

А теперь вот мой искренний и агностический совет всем, кто все еще считает, что Subversion достаточно хороша для обозримого будущего:

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

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