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

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

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

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

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

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

Похоже, что Git - это та самая "new, shiny, cool" штука. Это ни в коем случае не плохо (в конце концов, есть причина, по которой Лайнус написал его для разработки Linux Kernel), но я чувствую, что многие люди прыгают на поезд "Distributed Source Control" только потому, что он новый и написан Линусом Торвальдсом, на самом деле не зная, почему/если он лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Git имеет команду 'clean'. 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 позволяет иметь "private" игнорирование настроек (с помощью файла .git/info/exclude), что не повлияет ни на кого другого.

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

Кратко:

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

Есть и некоторые минусы:

• Для этого пока не так много хороших 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 Code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) возможность совершить изменения, не делая их достоянием общественности. В Subversion любое обязательство немедленно становится публичным и, следовательно, необратимым. Это значительно ограничивает возможности разработчика до "commit early, commit often".

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

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

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

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

Но вот в чем проблема: подрывная деятельность-это архитектурный тупик .

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

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

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

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

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

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

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

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

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

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

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

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

• Читайте диффы

• Git - это C инструментов контроля версий

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

• DVCS и DAGs, Часть 1

• DVCS и DAGs, Часть 2

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

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

• Почему Git так быстро идет?

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