Действительно ли это стоит идти к Мерзавцу от SVN для единственного разработчика?

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

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

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

исправление коммитов, git bisect. Просто потому, что вы один разработчик, нет причин не использовать лучшие инструменты.

git-svn - вы можете попробовать его параллельно с репозиториями Subversion, пока принимаете решение.

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

исправление коммитов, git bisect. Просто потому, что вы один разработчик, нет причин не использовать лучшие инструменты.

git-svn - вы можете попробовать его параллельно с репозиториями Subversion, пока принимаете решение.

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

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

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

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

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

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

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

git svn clone svn://mysvn/repo/

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

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

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

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

Да, конечно.

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

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

Плюсы:

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

Минусы:

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

ОБНОВЛЕНИЕ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вместо четырех коммитов вы видите только одну фиксацию в стволе. Это упрощает просмотр журнала, что происходит.

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

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

вместо четырех коммитов вы видите только одну фиксацию в стволе. Это упрощает просмотр журнала, что происходит.

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

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

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

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

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

I have used these systems in the manner which you describe, under Windows with Visual Studio 2008:

• Visual Source Safe
• Subversion
• Mercurial
• Git

If you value your life, do not ever use Visual Source Safe...

Subversion

• Pros: Excellent tools, both on the server and client side. VisualSVN and TortoiseSVN.
• Cons: It doesn't handle merging things too well.

Git

• Pros: Excellent merging support, fast.
• Cons: Windows tools are almost non-existent, the GUI ones that do exist are so horrible, I hope I don't ever have to use them again. (my opinion)

Mercurial

• Pros: Excellent merging support, decent tools. TortoiseHG and VisualHG, Python based - hook scripts can be written in Python, hooking directly into the HG api.
• Cons: Tools are not up to the same par as with SVN.