Стоит ли идти на Git из SVN для одного разработчика?

Ответ 1

Помимо того, что уже было сказано, если вы один разработчик и не испытывали проблем с SVN, я не вижу причин для переключения. svnserve (демон) работает нормально локально (у меня OS X).

TortoiseSVN - это благословение по сравнению с инструментами Git... есть ли какая-то особая причина, почему вы хотите отойти от Subversion?

Ответ 2

Я могу дать вам три преимущества:

• У вас может быть несколько резервных хранилищ. Git не централизована, поэтому вы можете сохранить свое репо на какой-либо машине, на которой работаете, и нажимать изменения в любых резервных местах, которые у вас есть. Я сохраняю свои репозитории на github и еще два других местоположения.
• Ветвление, слияние, перезагрузка, изменение коммитов, Git bisect. Просто потому, что вы один разработчик, нет оснований не использовать лучшие инструменты.
• git -svn - вы можете попробовать попробовать параллельно с вашими репозиториями subversion, пока вы делаете свой ум.

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

Ответ 3

Да, конечно.

Вы не понимаете, что такое git. Я имею в виду, почему вы считаете это полезным только для команд?

git еще более стоит того, если вы один разработчик.

Плюсы:

• svn требует, чтобы сервер работал в фоновом режиме. git С другой стороны, это простая утилита, вы просто запускаете ее, как если бы вы выполняли grep или ls или любую другую простую утилиту командной строки. Вам не нужно настраивать сервер или что-то в этом роде.
• Папка .git - это весь репозиторий, вы можете взять его с собой куда угодно (например, на USB-накопителе), и он всегда будет иметь ваше репо. Все ваше репо, а также его история и все остальное, и это очень сжато, поэтому он не занимает столько места. (Подсказка: почему git не нужен сервер, при запуске команд git git просто изменяет внутренности папки .git).
• Ветвление и слияние очень просто. Вы можете работать над экспериментальными новыми функциями на отдельной ветки и сливаться только при ее стабилизации. Тем временем вы можете выполнять техобслуживание на главной ветке (например, исправления ошибок) и все это время, когда вы можете легко слить исправления ошибок из ведущей ветки в свою экспериментальную (тему) ветку.
• Этот момент субъективен, но я нахожу его намного проще, чем svn. Я пытался использовать svn некоторое время, но обнаружил, что это слишком сложно, и часто это мешало мне (я точно не помню, что, что и почему, я просто знаю, что это был не приятный опыт). Например, переименование файлов не является проблемой. Вы можете переименовывать файлы, а git не будет суетиться, это просто не касается имени файла. Единственное, что вы должны помнить, добавить его после переименования, как будто вы создали новый файл.

Минусы:

• Не много визуальных инструментов. Там git -gui, это неплохо, (я не использовал его много), но вы не хотите зависеть от него. Вам нужно привыкнуть к его использованию из командной строки. Если вы привыкли к визуальным инструментам с помощью svn, это, может быть, конус, но, на мой взгляд, единственное, что вам нужно сделать, - это немного выйти из зоны комфорта, чтобы изучить его; но поверьте мне, это того стоит.
• Возможно, некоторые проблемы с завершением строки в Windows, это не большая проблема, если вы единственный разработчик, но если вы разрабатываете Windows и другие разрабатываете Linux, вам нужно убедиться, что все файлы используйте строку unix-style, которая заканчивается вместо окон ", чтобы избежать каких-либо проблем.
• Из-за отсутствия визуальных инструментов разрешение конфликтов (когда они появляются) может быть проблемой вначале. Я лично использую WinMerge и вызываю команду winmergeu <conflictfile> в каждом файле конфликта для разрешения конфликтов. (Примечание: WinMerge не является средством слияния с командной строкой, это визуальный инструмент слияния с обычным gui).
• Это подводит меня к другому моменту. Хотя начать работу с git очень легко, возможно, есть какая-то кривая обучения для решения проблем, возникающих позже (например, разрешения конфликтов). Если вы не разветвляетесь и не объединяетесь, тогда вы даже не столкнетесь с конфликтами, но опять же вам также не хватит очень мощной функции.

UPDATE:

Я не заметил, как вы работаете с нескольких разных машин.

Это не имеет значения, вам просто нужно помнить, что нужно нажимать и тянуть, когда вы переключаетесь на другую машину, но вы уже делаете это с помощью svn: commit/update.

Вы получите силу ветвления/слияния. Не недооценивайте эту мощность.

Сколько раз вы думали о реализации какой-то сумасшедшей идеи, но никогда не осмеливались это сделать, потому что вы не хотите испортить свой код? git избавляет вас от этих забот. Просто сделайте это в ветке, если это сработает, слейте его в основную ветку, если это не так, удалите ветку и забудьте об этом.

Конечно, вы можете сказать, что вы можете сделать то же самое с svn revert, возвращаясь к ревизии, прежде чем начать безумную идею. но что, если у вас были исправления ошибок, применяемые в то же время? Если вы вернете свою сумасшедшую идею, вы потеряете все исправления ошибок/работу по обслуживанию, которые вы сделали, экспериментируя со своей сумасшедшей идеей.

Ответ 4

Это зависит от вашего рабочего процесса. Вы часто работаете с места, где вы не можете связаться с вашим svn-сервером? У ваших проектов есть большое количество веток, потому что вам нравится работать над несколькими (большими) вещами одновременно? Вы копируете рабочие копии между машинами? Вы отделили новые ветки от существующей ветки? Вы иногда работаете на багажнике, а на полпути через кучу изменений думаете: "Я должен был сделать это в ветке"? Если это так, тогда это может быть полезно.

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

Пример. У вас есть большая функция F, которая состоит из изменений a, b, c и d. С Subversion вы либо совершаете a, b, c, и d отдельно на соединительной линии, либо создаете ветку, что означает, что вам нужно много слияния. С помощью git вы проверяете рабочую копию, фиксируете ее, b, c и d. Тогда вы подталкиваете это как одно изменение F к своему хозяину. Итак, вместо четырех коммитов вы видите только одну фиксацию на багажнике. Это облегчает просмотр в журнале того, что происходит.

Вы можете сделать это и с ветвями svn. Но теперь предположим, что часть а также состоит из нескольких частей, таких как a1 и a2.

Такая модель развития может быть выполнена с помощью Subversion. Например, Python Twisted выполняется таким образом. Все разработки проводятся по отраслям, и никто не работает на багажнике. Но git упрощает такой рабочий процесс.

Ответ 5

Я использовал эти системы так, как вы описываете, под Windows с Visual Studio 2008:

• Безопасность на Visual Source
• Subversion
• Mercurial
• Git

Если вы цените свою жизнь, не используйте когда-либо, используя Visual Source Safe...

Subversion

• Плюсы: отличные инструменты, как на сервере, так и на стороне клиента. VisualSVN и TortoiseSVN.
• Минусы: он слишком плохо справляется с слиянием.

Git

• Плюсы: Отличная поддержка слияния, быстро.
• Минусы: инструменты Windows почти не существуют, GUI, которые существуют, настолько ужасны, я надеюсь, что мне никогда не придется использовать их снова. (мое мнение)

Mercurial

• Плюсы: Отличная поддержка слияния, приличные инструменты. TortoiseHG и VisualHG, на основе Python скрипты могут быть написаны на Python, напрямую подключаясь к HG api.
• Минусы: инструменты не соответствуют тем же параметрам, что и SVN.

Ответ 6

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

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

Обновление: Заметьте, что вы можете протестировать Git, не связываясь с ним, поскольку Git может разговаривать с SVN-репозиториями. Так что попробуйте, и если вам это не нравится, ничего не потеряно!

Ответ 7

Просто попробуйте, установите msysgit, затем

git svn clone svn://mysvn/repo/

Некоторые ресурсы в Git для начинающих: окончательное практическое руководство должно помочь (Gitcasts и Git Magic)

Лично я нахожу git гораздо приятнее в использовании. Я переключил свои личные SVN-репозиции на git около двух лет назад и не имел ни одной проблемы с ним когда-либо

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

Как правило, "очень быстро" (почти каждое действие в основном мгновенно), все работает "в автономном режиме", клоны - это полные резервные копии. Но основная причина, по которой я продолжаю использовать, - Github

Ответ 8

Нет. По крайней мере не для меня. Какой смысл иметь нецентрализованное репо для одного разработчика?

Кроме того, инструменты Git Windows не совсем подходят для панели TortoiseSVN.

Ответ 9

Посмотрите на базар (bzr). Серьезно, это потрясающе. Лучшая возможность слияния, которую я видел.

Ответ 10

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

• Svn довольно громоздкий, он помещает свои вещи (папки .svn) повсюду. Это затрудняет использование общих инструментов командной строки, таких как grep (и многие другие) в репозиториях .svn. В моем проекте у меня также была процедура установки, которая должна была скопировать полное дерево реестров на какой-то системный путь. При использовании svn мне пришлось писать дополнительный код (или экспортировать репозиторий), просто чтобы избежать того, что моя процедура установки также скопирует .svn. Подобные проблемы полностью исчезли с помощью Git. Все находится в директории one.git в корневом каталоге репозитория.

В настоящее время (2/2013) есть только одна папка .svn в корневой папке!

• У меня было несколько неудачных опытов с моим svn-клиентом в Linux, казалось бы, простыми действиями, такими как перемещение файла, а затем его изменение до совершения зависания системы с использованием 100% -ного CPU! (И нет, это не было чем-то еще, что вызвало крушение, и я мог повторить его по желанию). Никогда не сталкивались с такими проблемами с инструментами Git.

• У меня также было какое-то ужасное время слияния кода между туловищем и стабильной ветвью в моем старом svn-репозитории. Это проще с помощью Git.

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

Ответ 11

Если вы привыкли к Tortoise SVN, вам следует попробовать Mercurial, у которого есть пакет Windows с аналогичным расширением оболочки Tortoise HG. Также Джоэл Спольский использует Mercurial в Fog Creek (по его словам, в одном из своих подкастов).

Пакет полностью автономный, я смог сразу установить и использовать Mercurial (даже не нужен сервер!)