Я использую Subversion в течение нескольких лет, и после использования SourceSafe , я просто люблю Subversion. В сочетании с TortoiseSVN я не могу себе представить, как это может быть лучше.
Тем не менее, растет число разработчиков, утверждающих, что у Subversion есть проблемы и что мы должны перейти к новому поколению распределенных систем контроля версий, таких как Git .
Как Git улучшается в Subversion?
Ответы:
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 блестят.
С Git вы можете делать практически все в автономном режиме, потому что у каждого есть свой собственный репозиторий.
Создание веток и слияние веток действительно легко.
Даже если у вас нет прав на коммит для проекта, вы все равно можете иметь свой собственный репозиторий онлайн и публиковать «push-запросы» для своих патчей. Все, кому нравятся ваши патчи, могут включить их в свой проект, включая официальных сопровождающих.
Тривиально спроектировать проект, изменить его и продолжать объединять исправления ошибок из ветки HEAD.
Git работает для разработчиков ядра Linux. Это означает, что это действительно быстро (это должно быть), и масштабируется до тысяч участников. Git также использует меньше места (до 30 раз меньше места для хранилища Mozilla).
Git очень гибкий, очень TIMTOWTDI (есть несколько способов сделать это). Вы можете использовать любой рабочий процесс, который захотите, и Git его поддержит.
Наконец, есть GitHub , отличный сайт для размещения ваших Git-репозиториев.
Недостатки Git:
Другие ответы хорошо объяснили основные функции Git (и это здорово). Но есть также так много маленьких способов, которыми Git ведет себя лучше и помогает сохранять мою жизнь более разумной. Вот некоторые мелочи:
git mvи git rm.
« Почему Git лучше, чем X » описывает различные плюсы и минусы Git против других SCM.
Кратко:
Есть некоторые недостатки:
В наиболее простом использовании 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 действительно сияет, так это ветвление и работа с другими людьми.
Google Tech Talk: Линус Торвальдс на Git
http://www.youtube.com/watch?v=4XpnKHJAok8
Страница сравнения Git Wiki
Ну, это распространяется. Тесты показывают, что он значительно быстрее (учитывая его распределенную природу, такие операции, как diff и log-файлы все локальные, поэтому, конечно, в этом случае он работает невероятно быстро), а рабочие папки меньше (что все еще поражает воображение).
Когда вы работаете над Subversion или любой другой клиент-серверной системой контроля версий, вы по сути создаете рабочие копии на своем компьютере, проверяя версии. Это представляет собой моментальный снимок того, как выглядит хранилище. Вы обновляете свою рабочую копию с помощью обновлений, а вы обновляете хранилище с помощью коммитов.
С распределенным управлением версиями у вас нет снимка, а всего кода. Хотите сделать различие с 3-месячной версией? Нет проблем, 3-месячная версия все еще на вашем компьютере. Это не только означает, что дела идут намного быстрее, но если вы отключены от центрального сервера, вы все равно можете выполнять многие операции, к которым вы привыкли. Другими словами, у вас есть не только снимок данной ревизии, но и всего кода.
Можно подумать, что Git займет много места на вашем жестком диске, но из пары тестов, которые я видел, на самом деле это займет меньше. Не спрашивай меня как. Я имею в виду, что он был построен Линусом, он, наверное, кое-что знает о файловых системах.
Основные моменты, которые мне нравятся в DVCS:
Основная причина относительно большого проекта - улучшенная коммуникация, созданная пунктом 3. Другие - приятные бонусы.
Самое смешное: я размещаю проекты в Subversion Repos, но получаю к ним доступ через команду Git Clone.
Пожалуйста, прочитайте Разработка с Git на Google Code Project
Хотя Google Code изначально говорит на Subversion, вы можете легко использовать Git во время разработки. Поиск «git svn» предполагает, что эта практика широко распространена, и мы также рекомендуем вам поэкспериментировать с ней.
Использование Git в репозитории Svn дает мне следующие преимущества:
backup/public репозиторий SVN для других, чтобы проверитьВсе ответы здесь, как и ожидалось, ориентированы на программиста, однако что произойдет, если ваша компания использует контроль версий за пределами исходного кода? Есть много документов, которые не являются исходным кодом, которые выигрывают от контроля версий, и должны жить рядом с кодом, а не в другой CMS. Большинство программистов не работают изолированно - мы работаем для компаний как часть команды.
Имея это в виду, сравните простоту использования, как в инструментах клиента, так и в обучении, между Subversion и git. Я не вижу сценария, когда какую-либо распределенную систему контроля версий будет проще использовать или объяснить непрограммисту. Я бы хотел оказаться ошибочным, потому что тогда я смог бы оценить git и действительно иметь надежду, что его примут люди, которым нужен контроль версий, но не программисты.
Даже тогда, если руководство спросит, почему мы должны перейти от централизованной к распределенной системе контроля версий, мне будет сложно дать честный ответ, потому что он нам не нужен.
Отказ от ответственности: я заинтересовался Subversion на ранних этапах (около v0.29), так что, очевидно, я предвзят, но компании, в которых я работал с тех пор, извлекают выгоду из моего энтузиазма, потому что я поощрял и поддерживал его использование. Я подозреваю, что так происходит с большинством компаний-разработчиков программного обеспечения. Интересно, так как многие программисты используют git-фургон, сколько компаний собираются упустить преимущества использования контроля версий вне исходного кода? Даже если у вас есть отдельные системы для разных групп, вы упускаете некоторые преимущества, такие как (унифицированная) интеграция с отслеживанием проблем, при одновременном повышении требований к обслуживанию, оборудованию и обучению.
Subversion - все еще намного более используемая система контроля версий, что означает, что она имеет лучшую поддержку инструмента. Вы найдете зрелые плагины SVN практически для любой IDE , и есть хорошие расширения для проводника (например, TurtoiseSVN). Кроме этого, я должен согласиться с Майклом : Git не лучше и не хуже Subversion, он другой.
Одна из особенностей SubVersion, которая меня раздражает, заключается в том, что она помещает свою собственную папку в каждый каталог проекта, тогда как git помещает только одну в корневой каталог. Это не что большой сделки, но такие мелочи , как , что складывают.
Конечно, у SubVersion есть Turtoise, что [обычно] очень приятно.
Дэвид Ричардс WANdisco Блог о Subversion / GIT
Появление GIT привело к порождению фундаменталистов DVCS - «Gitterons», которые думают, что все, кроме GIT, является дерьмом. Гиттероны, кажется, думают, что разработка программного обеспечения происходит на их собственном острове, и часто забывают, что большинство организаций не нанимают исключительно старших разработчиков программного обеспечения. Это нормально, но это не так, как думает остальная часть рынка, и я рад это доказать: у GIT, по последним данным, было менее трех процентов рынка, в то время как у Subversion было пять миллионов пользователей и около половины общий рынок.
Проблема, которую мы видели, состояла в том, что Гиттероны стреляли (дешевыми) выстрелами в Subversion. Твиты типа «Subversion такой [медленный / дрянной / ограничительный / плохо пахнет / смешно смотрит на меня], и теперь у меня есть GIT и [все работает в моей жизни / моя жена забеременела / у меня появилась девушка после 30 лет попыток / я шесть раз побеждал на столе в блэкджеке]. Вы получаете картину.
Git также упрощает ветвление и слияние. Subversion 1.5 только что добавил отслеживание слияний, но Git все еще лучше. С Git ветвление очень быстро и дешево. Это делает создание ветки для каждой новой функции более осуществимым. Репозитории Oh и Git очень эффективны с пространством хранения по сравнению с Subversion.
Все дело в простоте использования / шагах, необходимых для того, чтобы что-то сделать.
Если я разрабатываю один проект на своем ПК / ноутбуке, лучше использовать git, потому что его гораздо проще настроить и использовать. Вам не нужен сервер, и вам не нужно вводить URL-адреса хранилища, когда вы делаете слияния.
Если бы это было всего 2 человека, я бы сказал, что git также проще, потому что вы можете просто толкать и тянуть друг друга.
Однако, как только вы выйдете за пределы этого, я пойду на подрывную деятельность, потому что в этот момент вам нужно настроить «выделенный» сервер или местоположение.
Вы можете сделать это так же хорошо с git, как и с SVN, но преимущества git перевешиваются необходимостью выполнять дополнительные шаги для синхронизации с центральным сервером. В SVN вы просто делаете коммит. В git вы должны сделать git commit, затем git push. Дополнительный шаг раздражает просто потому, что в итоге вы делаете это очень много.
У SVN также есть преимущество более совершенных инструментов с графическим интерфейсом, однако экосистема git, похоже, быстро догоняет, поэтому я не буду беспокоиться об этом в долгосрочной перспективе.
В Easy Git есть хорошая страница, сравнивающая фактическое использование Git и SVN, которая даст вам представление о том, что Git может делать (или делать более легко) по сравнению с SVN. (Технически, это основано на Easy Git, который является легкой оболочкой поверх Git.)
Git и DVCS в целом отлично подходят для разработчиков, которые много пишут независимо друг от друга, потому что у каждого своя ветвь. Однако, если вам нужно изменение от кого-то другого, она должна совершить свое локальное репо, а затем она должна передать вам этот набор изменений, или вы должны получить его от нее.
Мои собственные соображения также заставляют меня думать, что DVCS усложняет контроль качества и управление выпусками, если вы делаете такие вещи, как централизованные выпуски. Кто-то должен нести ответственность за выполнение этого push / pull из репозитория всех остальных, разрешение любых конфликтов, которые были бы разрешены при первоначальном времени фиксации ранее, затем выполнение сборки и затем повторную синхронизацию всех остальных разработчиков своих репозиториев.
Конечно, все это можно решить с помощью человеческих процессов; DVCS просто сломал что-то, что было исправлено централизованным контролем версий, чтобы обеспечить некоторые новые удобства.
Мне нравится Git, потому что он на самом деле помогает коммуникационному разработчику разработчику в средней и большой команде. Как распределенная система контроля версий, благодаря своей системе push / pull она помогает разработчикам создавать экосистему исходного кода, которая помогает управлять большим количеством разработчиков, работающих над одним проектом.
Например, скажем, вы доверяете 5 разработчикам и извлекаете только коды из их репозитория. Каждый из этих разработчиков имеет свою собственную сеть доверия, откуда они получают коды. Таким образом, разработка основана на той структуре доверия разработчиков, в которой ответственность за код распределяется между сообществом разработчиков.
Конечно, есть и другие преимущества, которые упоминаются в других ответах здесь.
Несколько ответов были упомянуты на них, но я хочу сделать два явных замечания:
1) Возможность делать выборочные коммиты (например, git add --patch). Если ваш рабочий каталог содержит несколько изменений, которые не являются частью одного и того же логического изменения, Git очень легко делает фиксацию, которая включает только часть изменений. С Subversion это сложно.
2) Возможность совершать изменения без публикации изменений. В Subversion любой коммит является сразу открытым и, следовательно, безотзывным. Это сильно ограничивает способность разработчика «делать коммиты рано, часто».
Git - это больше, чем просто VCS; это также инструмент для разработки патчей. Subversion - это просто VCS.
Я думаю, что с Subversion все в порядке ... пока вы не начнете объединяться ... или делать что-то сложное ... или делать что-то, что Subversion считает сложным (например, выполнять запросы, чтобы выяснить, какие ветви связаны с определенным файлом, откуда на самом деле происходят изменения , обнаруживать копии и вставки , так далее)...
Я не согласен с победным ответом, сказав, что основным преимуществом GIT является работа в автономном режиме - это, безусловно, полезно, но это больше похоже на дополнительное в моем случае использования. SVK тоже может работать в автономном режиме, но у меня нет никаких сомнений в том, в какое время я потрачу время на обучение.
Просто он невероятно мощный, быстрый и, ну, после привыкания к концепциям, очень полезный (да, в этом смысле: удобный для пользователя).
Для получения более подробной информации об истории слияния смотрите: Использование git-svn (или аналогичного) * просто *, чтобы помочь слиянием svn?
Благодаря тому, что ему не нужно постоянно обмениваться данными с центральным сервером, почти каждая команда выполняется менее чем за секунду (очевидно, что git push / pull / fetch медленнее просто потому, что им нужно инициализировать соединения SSH). Ветвление намного проще (одна простая команда для ветвления, одна простая команда для объединения)
Мне очень нравится, что я могу управлять локальными ветвями моего исходного кода в Git, не пачкая воды центрального хранилища. Во многих случаях я извлекаю код с сервера Subversion и запускаю локальный репозиторий Git, чтобы сделать это. Также замечательно, что инициализация Git-репозитория не загрязняет файловую систему кучей раздражающих папок .svn повсюду.
Что касается поддержки инструментов Windows, TortoiseGit очень хорошо справляется с основами, но я все же предпочитаю командную строку, если не хочу просматривать журнал. Мне очень нравится, как Tortoise {Git | SVN} помогает при чтении логов коммитов.
Это неправильный вопрос. Слишком легко сосредоточиться на бородавках git и сформулировать аргумент о том, почему subversion якобы лучше, по крайней мере, для некоторых случаев использования. Тот факт, что git изначально разрабатывался как низкоуровневый конструктор контроля версий и имеет интерфейс, ориентированный на разработчиков в стиле барокко, облегчает священным войнам набирать обороты и обретает легитимность. Сторонники Git бьют по барабану миллионами преимуществ рабочего процесса, которые svn ребята объявляют ненужными. Довольно скоро вся дискуссия становится централизованной и распределенной, что служит интересам сообщества разработчиков инструментальных средств для предприятий. Эти компании, которые обычно публикуют самые убедительные статьи о превосходстве Subversion на предприятии,
Но вот проблема: Subversion - это тупик архитектуры .
Принимая во внимание, что вы можете взять git и создать централизованную замену subversion довольно легко, несмотря на то, что 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 или многие другие.
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 в наши дни это командная строка
Эрик Синк из SourceGear написал серию статей о различиях между распределенными и нераспределенными системами контроля версий. Он сравнивает плюсы и минусы большинства популярных систем контроля версий. Очень интересное чтение.
Статьи можно найти в его блоге, www.ericsink.com :
Для людей, которые ищут хороший графический интерфейс Git, Syntevo SmartGit может быть хорошим решением. Я считаю, что его проприетарное, но бесплатное для некоммерческого использования, работает на Windows / Mac / Linux и даже поддерживает SVN, используя какой-то мост git-svn.
http://subversion.wandisco.com/component/content/article/1/40.html
Я думаю, что можно с уверенностью сказать, что среди разработчиков SVN Vs. Спор Git бушевал в течение некоторого времени, и каждый имеет свой взгляд на то, что лучше. Это было затронуто даже во время нашего вебинара по Subversion в 2010 году и далее.
Хайрам Райт, наш директор Open Source и президент корпорации Subversion, рассказывает о различиях между Subversion и Git, а также другими распределенными системами контроля версий (DVCS).
Он также рассказывает о предстоящих изменениях в Subversion, таких как Working Copy Next Generation (WC-NG), которые, по его мнению, заставят многих пользователей Git перейти обратно в Subversion.
Посмотрите его видео и сообщите нам, что вы думаете, комментируя этот блог или публикуя его на наших форумах. Регистрация проста и займет всего минуту!
Git в Windows довольно хорошо поддерживается сейчас.
Проверьте GitExtensions = http://code.google.com/p/gitextensions/
и руководство для лучшего опыта работы с Windows Git.
В последнее время я живу на Git Land, и мне нравится это для личных проектов, но я пока не смогу переключать на него рабочие проекты с Subversion, учитывая изменение мышления, которое требуется от персонала, без каких-либо неотложных преимуществ. Более того, самый большой проект, который мы запускаем внутри компании, чрезвычайно зависит от svn: externals, который, из того, что я видел до сих пор, не очень хорошо и без проблем работает в Git.
Во-первых, параллельное управление версиями кажется простой задачей для решения. Это совсем не так. Тем не мение...
SVN совершенно не интуитивно понятен. Мерзавец еще хуже. [sarcastic-speculation] Это может быть потому, что разработчики, которым нравятся сложные проблемы, такие как параллельное управление версиями, не очень заинтересованы в создании хорошего пользовательского интерфейса. [/ Саркастичное-предположение]
Сторонники SVN считают, что им не нужна распределенная система контроля версий. Я тоже так думал. Но теперь, когда мы используем исключительно Git, я верующий. Теперь у меня работает контроль версий И команда / проект, а не просто работа над проектом. Когда мне нужна ветка, я ветвлюсь. Иногда это ветвь с соответствующей веткой на сервере, а иногда ее нет. Не говоря уже о всех других преимуществах, над которыми мне придется поработать (отчасти благодаря таинственному и абсурдному отсутствию пользовательского интерфейса, который является современной системой контроля версий).
Почему я думаю, что Subversion лучше, чем Git (по крайней мере, для проектов, над которыми я работаю), в основном из-за его удобства использования и более простого рабочего процесса:
http://www.databasesandlife.com/why-subversion-is-better-than-git/