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

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

создание ветвей и слияние между ветвями очень легко.

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

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

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

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

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

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

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

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

1. Git имеет "чистую" команду. SVN отчаянно нуждается в этой команде, учитывая, как часто она будет сбрасывать дополнительные файлы на ваш диск.
2. Git имеет команду "bisect". Это мило.
3. SVN создает .svn каталоги в каждой папке (Git создает только один .git directory). Каждый сценарий, который вы пишете, и каждый grep, который вы делаете, должны быть написаны, чтобы игнорировать их .каталоги в SVN. Вам также нужна целая команда ("SVN export"), чтобы получить нормальную копию ваших файлов.
4. в SVN каждый файл и папка могут поступать из разных версий или ветвей. Поначалу приятно иметь такую свободу. Но на самом деле это означает, что существует миллион различных способов для вашего местная проверка будет полностью испорчена. (например, если" SVN switch " терпит неудачу на полпути, или если вы вводите команду неправильно). И самое худшее: если вы когда-нибудь попадете в ситуацию, когда некоторые из ваших файлов поступают из одного места, а некоторые из них из другого, "статус svn" скажет вам, что все нормально. Вам нужно будет сделать "svn info" Для каждого файла/каталога, чтобы узнать, насколько странные вещи. Если "git status" говорит вам, что все нормально, вы можете доверять этим вещам действительно нормальные.
5. вы должны сказать SVN, когда вы перемещаете или удаляете что-то. ГИТ просто разберется.
6. игнорировать семантику проще в Git. Если вы игнорируете шаблон (например,*.pyc), он будет проигнорирован для все подкаталоги. (Но если вы действительно хотите игнорировать что-то только для одного каталога, вы можете). С SVN кажется, что нет простого способа игнорировать шаблон во всех подкаталогах.
7. еще один элемент, связанный с игнорированием файлов. Git позволяет иметь" частные " настройки игнорирования (используя файл .git / info / exclude), который не повлияет ни на кого другого.

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

кратко:

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

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

• для этого еще не так много хороших GUIs. Это новое, и 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 действительно сияет, это ветвление и работа с другими людьми.

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

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

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

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

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

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

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

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

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

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

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

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

читайте разработка с Git на проекте кода Google

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

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

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

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

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

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

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

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

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

конечно, SubVersion имеет черепаху, что [обычно] очень приятно.

Дэвид Ричардс Wandisco блог на Subversion / GIT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но вот в чем проблема:Subversion является архитектурным тупик.

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

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

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

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

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

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

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

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

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

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

• читать диффы

• Git-это C управления версиями Инструменты

• о недостатке уважения Git к неизменности и лучшим практикам для DVCS

• DVCS и DAG, Часть 1

• DVCS и DAG, Часть 2

• DVCS и отслеживание ошибок

• объединить историю, DAGs и Darcs

• почему Git так Быстро?

• Mercurial, Subversion и Уэсли Снайпс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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