Ось копія відповіді, яку я з тих пір видалив із дублюючого питання про Git vs. 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 can.
Знову ж таки, їхня природа принципово інша (що потім призводить до різного впровадження, але це не суть).
Одні бачать керування редакцією як каталоги та файли, інші бачать лише вміст файлу (настільки, що порожні каталоги навіть не зареєструються в Git!).
Загальна кінцева мета може бути однаковою, але ви не можете їх використовувати однаково, а також не можете вирішити той самий клас проблем (за обсягом або складністю).