Стоит ли переходить на Git из SVN для одного разработчика? - PullRequest
25 голосов
/ 29 мая 2009

--- НАСТОЯЩАЯ РЕЗЬБА ОЧЕНЬ ВЕРОЯТНО УСТАРЕЛА НА 2013 ГОД --- --- 1002 *

Стоит ли идти в GIT из SVN, когда к репозиториям в основном обращается один разработчик? У меня есть несколько машин, которые я использую для разработки, а не для разработки в основном на C #. Но у меня есть смесь VB, VB.Net, PHP, C #, C ++, HTML, Batch, BASH и многих других в моих репозиториях. Что, если что, я получу, перейдя на GIT из SVN? Прямо сейчас используйте TortoiseSVN + VisualSVN Server с набором центральных репозиториев и несколькими клиентскими машинами. Хотя я предоставил нескольким друзьям доступ к своим репозиториям, они не обновляют и не фиксируют их часто (если вообще когда-либо).

Также есть ли способ получить гибкость и простоту обслуживания, которые я получаю с VisualSVN Server + TortiseSVN с Git?

((Я укушу ... какие другие платформы и хитрости будут привлекательны для одного разработчика / небольшой группы?)

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

Текущая цепочка инструментов ... Visual Studio 2008 (C # / VB.Net) + TortoiseSVN + VisualSVN

Основной фокус ... XNA Games, WCF / Socket Services, веб-разработка

Ответы [ 11 ]

23 голосов
/ 29 мая 2009

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

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

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

15 голосов
/ 29 мая 2009

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

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

15 голосов
/ 29 мая 2009

Да, конечно.

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

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

Плюсы:

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

Минусы:

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

UPDATE:

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

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

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

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

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

8 голосов
/ 29 мая 2009

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

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

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

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

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

5 голосов
/ 29 мая 2009

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

  • Visual Source Safe
  • * 1006 Subversion *
  • Mercurial
  • 1010 * Гит *

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

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

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

Mercurial

  • Плюсы: отличная поддержка слияния, достойные инструменты. TortoiseHG и VisualHG , основанные на Python - скрипты ловушек могут быть написаны на Python, подключаясь непосредственно к HG API.
  • Минусы: инструменты не соответствуют тем же параметрам, что и SVN.
4 голосов
/ 29 мая 2009

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

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

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

3 голосов
/ 29 мая 2009

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

git svn clone svn://mysvn/repo/

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

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

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

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

2 голосов
/ 29 мая 2009

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

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

1 голос
/ 19 мая 2011

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

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

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

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

  • У меня также было несколько ужасных моментов, когда я сливал код между стволом и стабильной веткой в ​​моем старом svn-хранилище. С Git действительно проще.

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

1 голос
/ 29 мая 2009

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

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