Вот копия ответа, который я сделал на некоторый повторяющийся вопрос с тех пор, как он был удален о Git против SVN (сентябрь 2009 г.).
Лучше? Помимо обычной ссылки WhyGitIsBetterThanX , они разные:
одна - центральная VCS, основанная на дешевой копии для веток и тегов, другая (Git) - распределенная VCS, основанная на графе ревизий. Смотрите также Основные понятия VCS .
Эта первая часть вызвала некоторые неосведомленные комментарии, притворяясь, что основная цель двух программ (SVN и Git) одинакова, но они были реализованы совершенно по-разному.
Чтобы прояснить принципиальную разницу между SVN и Git , позвольте мне перефразировать:
SVN является третьей реализацией контроля версий : RCS, затем CVS и, наконец, SVN управляют каталогами версионных данных. SVN предлагает функции VCS (маркировка и слияние), но его тег - это просто копия каталога (например, ветвь, за исключением того, что вы не «должны» что-либо трогать в каталоге тегов), и его объединение все еще сложно, в настоящее время основанное на метаданных -данные добавлены, чтобы вспомнить, что уже было объединено.
Git - это управление содержимым файлов (инструмент, созданный для объединения файлов), превращенный в настоящую систему управления версиями , основанную на DAG ( направленном ациклическом графе ) коммитов, где ветви являются частью истории данных (а не самими данными). ) и где теги являются истинными метаданными.
Сказать, что они «принципиально» не разные, потому что вы можете достичь одного и того же, решить одну и ту же проблему, - это просто ложь на стольких уровнях.
- если у вас много сложных слияний, выполнение их с SVN будет более длительным и более подверженным ошибкам. если вам нужно создать много веток, вам нужно будет управлять ими и объединять их, опять же, намного проще с Git, чем с SVN, особенно если задействовано большое количество файлов (скорость становится важной)
- если у вас есть частичное слияние для незавершенной работы, вы воспользуетесь областью размещения Git (индекс), чтобы зафиксировать только то, что вам нужно, спрятать остальное и перейти к другой ветке.
- если вам нужна автономная разработка ... хорошо, с Git вы всегда «онлайн», со своим собственным локальным репозиторием, независимо от того, какой рабочий процесс вы хотите использовать с другими репозиториями.
Тем не менее, комментарии к этому старому (удаленному) ответу настаивали:
VonC: Вы путаете фундаментальное различие в реализации (различия очень фундаментальные, мы оба четко согласны с этим) с различием в целях.
Оба эти инструмента используются для одной и той же цели: именно поэтому многие команды, которые ранее использовали SVN, довольно успешно смогли отказаться от него в пользу Git.
Если бы они не решили ту же проблему, такой заменяемости не было бы.
, на что я ответил:
«заменяемость» ... интересный термин ( используется в компьютерном программировании ).
Конечно, Git вряд ли является подтипом SVN.
Вы можете получить те же технические возможности (тег, ветвь, слияние) с обоими, но Git не мешает вам и позволяет вам сосредоточиться на содержимом файлов , не думая о самом инструменте.
Вы, конечно, не можете (всегда) просто заменить SVN на Git «без изменения каких-либо желательных свойств этой программы (корректность, выполненная задача, ...)» (что является ссылкой на вышеупомянутое определение замещаемости ):
- Один - это расширенный инструмент ревизий, другой - настоящая система контроля версий.
- Один подходит для небольших и средних монолитных проектов с простым рабочим процессом слияния и (не слишком много) параллельных версий. Для этого достаточно SVN, и вам могут не понадобиться все функции Git.
- Другой позволяет использовать средние и большие проекты на основе нескольких компонентов (по одному репо на компонент ), с большим количеством файлов для слияния между несколькими ветвями в сложном рабочем процессе слияния, параллельными версиями в ветвях, слияниями модернизации и так далее. Вы можете сделать это с SVN, но вам гораздо лучше с Git.
SVN просто не может управлять любым проектом любого размера с любым рабочим процессом слияния. Мерзавец может.
Опять же, их природа принципиально иная (что приводит к разной реализации, но это не главное).
Один видит контроль версий как каталоги и файлы, другой видит только содержимое файла (настолько, что пустые каталоги даже не регистрируются в Git!).
Общая конечная цель может быть одинаковой, но вы не можете использовать их одинаково и не можете решить один и тот же класс проблем (по объему или сложности).