GIT или SVN или ... для разработчиков

Question

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

Причина, по которой я выбрал SVN, а не GIT, заключается в том, что я хочу, чтобы каждый в команде, включая дизайнеров, фронтменов, интеграторов ... взял на себя ответственность за свою собственную SCM, и поэтому я ожидаю, что дела пойдут быстрееих работа с использованием графического интерфейса (Cornerstone для Mac и Tortoise SVN для Windows).Я знаю, что есть некоторые графические интерфейсы GIT, SmartGit выглядит наиболее привлекательным в данный момент, но ни один из них не выглядит таким же способным, как их коллеги SVN.Кроме того, я чувствую, что мы потеряли бы что-то в переводе, если бы не использовали командную строку для работы с DVCS (тогда как я значительно счастливее, используя графический интерфейс для управления проектами в SVN).

Проблема в том, чтоРаспределенные решения быстро обгоняют централизованные решения, и поэтому мне интересно, стоило ли бы это сейчас делать дополнительные инвестиции, вместо того, чтобы перенести все 6 месяцев подряд и все равно потратить время на DVCS?Другой способ взглянуть на это состоит в том, что SVN будет тем временем относительно безболезненным шагом, который подготовит нас более адекватно, если мы позже решим перейти на DVCS.

Ваши мысли и опыт приветствуются.

* В сторону: по ряду причин я предпочитаю несколько проектов на один репозиторий SVN.Это, однако, означает менее значимую статистику из «Рыбий глаз» Атлассиана, а также является более грязной.Если бы мы решили использовать GIT, это был бы 1 репозиторий на проект.

Answer 1

Одна вещь, о которой нужно помнить о DVCS, заключается в том, что речь идет не о ее распределенности, а о ветвлении и слиянии. DVCS значительно упрощает ветвление и слияние, так что каждый разработчик / дизайнер / front-ender имеет свою собственную частную ветвь - локальное репо. Таким образом, они могут работать параллельно, не наступая друг другу на ноги. Это означает, что они могут проверять код каждые несколько часов, а не ждать дни, пока у них не будет сделано все для его проверки.

Я бы посоветовал вам взглянуть на Mercurial. Он имеет хороший графический интерфейс в TortoiseHg , и я считаю, что с ним легче начать, чем в Git, просто потому, что он не предоставляет вам все продвинутые вещи в самом начале, но он все еще имеет все из мощных функций, как только они чувствуют себя комфортно в системе.

Answer 2

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

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

Answer 3

Конечно, распределённость хороша, но если у svn были те же нераспределенные функции, что и у git, то только opensource-люди, работающие над большими проектами, начали использовать git.Слияние и ветвление - это очень хорошо, но более того: если вы что-то напортачили, то, как правило, очень легко решить проблему при использовании git.Или, если ваш исходный код полон изменений, и вам нужно быстро решить проблему с «основным кодом», git экономит много времени.Когда мы начали использовать svn в моей компании, у нас было много проблем с этим.Главным образом потому, что ему не хватает гибкости.

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

Answer 4

Попробуйте и познакомьте нескольких пользователей с TortiseGit. В зависимости от того, как они реагируют на это, вы можете решить, будет ли работать на команду. Если они борются с этим больше недели или около того, попробуйте SVN.

Если бы они действительно чувствовали себя более комфортно в SVN, чем я бы согласился. Опытные разработчики все еще могут использовать git-svn для использования большинства расширенных функций git.