Основна відмінність полягає в тому, що (як вже було сказано в інших відповідях) CVS - це (стара) централізована система управління версіями, тоді як Git поширюється.
Але навіть якщо ви використовуєте керування версіями для одного розробника, на одній машині (єдиний обліковий запис) є кілька відмінностей між Git та CVS:
Налаштування сховища . Git зберігає сховище у .gitкаталозі у верхньому каталозі вашого проекту; CVS вимагає налаштування CVSROOT, центрального місця для зберігання інформації про контроль версій для різних проектів (модулів). Наслідком цього дизайну для користувача є те, що імпорт існуючих джерел до контролю версій настільки ж простий, як "git init && git add. && git commit" в Git, в той час як у CVS він складніший .
Атомні операції . Оскільки CVS на початку являв собою набір сценаріїв навколо файлової системи управління версіями RCS, коміти (та інші операції) не є атомними в CVS; якщо операція з сховищем перервана посередині, сховище може залишитись у непослідовному стані. У Git всі операції є атомними: або вони досягають успіху в цілому, або провалюються без будь-яких змін.
Набори змін . Зміни в CVS входять до файлу, тоді як зміни (фіксації) в Git вони завжди стосуються всього проекту. Це дуже важливий зміна парадигми . Одним із наслідків цього є те, що в Git дуже легко повернути (створити зміну, яка скасовує) або скасувати цілі зміни; Інший наслідок полягає в тому, що в CVS легко робити часткові каси, в той час як це в даний час поруч із неможливим в Git. Той факт, що зміни в одному файлі, згруповані разом, призвели до створення формату GNU Changelog для передачі повідомлень у CVS; Користувачі Git використовують (і деякі інструменти Git очікують) різні умови, з єдиним рядком, що описує (підсумовує) зміну, а потім порожній рядок з подальшим детальним описом змін.
Назви ревізії / номери версій . Існує ще одна проблема, пов’язана з тим, що в CVS зміни входять до файлів: номери версій (як ви бачите іноді в розширенні ключових слів , див. Нижче), як 1.4, відображає, скільки часу було змінено даний файл. У Git кожна версія проекту в цілому (кожен комітет) має свою унікальну назву, що надається ідентифікатором SHA-1; Зазвичай перших 7-8 символів достатньо для ідентифікації фіксації (ви не можете використовувати просту схему нумерації версій у розподіленій системі управління версіями - для цього потрібен центральний орган нумерації). У CVS, щоб мати номер версії або символічну назву, що стосується стану проекту в цілому, ви використовуєте теги; те саме стосується Git, якщо ви хочете використовувати ім’я типу "v1.5.6-rc2" для певної версії проекту ... але теги в Git набагато простіше у використанні.
Легке розгалуження . Галузі в CVS, на мою думку, надмірно складні, і важко з цим боротися. Ви повинні позначити гілки, щоб мати ім’я для цілої гілки репозиторію (і навіть це може вийти з ладу, якщо я правильно пам’ятаю, через обробку файлів). Додайте до цього той факт, що у CVS немає відстеження злиття , тому вам потрібно або запам'ятати, або вручну позначити злиття та точки розгалуження та вручну подати правильну інформацію для "cvs update -j" для об'єднання гілок, і це робить для розгалуження. бути непотрібним важким у використанні. У Git створення та об'єднання гілок дуже просто; Git самостійно запам'ятовує всю необхідну інформацію (так що об'єднувати гілку так само просто, як "git merge назва гілки ") ... це довелося, тому що розподілений розвиток, природно, призводить до декількох гілок.
Це означає, що ви можете використовувати тематичні гілки , тобто розробляти окрему функцію в кілька етапів в окремій гілці функцій.
Перейменуйте (і скопіюйте) відстеження . Перейменування файлів не підтримуються в CVS, і перейменування вручну може порушити історію вдвічі або призвести до недійсної історії, коли ви не можете правильно відновити стан проекту перед перейменуванням. Git використовує евристичне виявлення перейменувань на основі схожості вмісту та імені файлу (Це рішення добре працює на практиці). Ви також можете подати запит на виявлення копіювання файлів. Це означає що:
- вивчаючи вказану комісію, ви отримаєте інформацію про те, що якийсь файл було перейменовано,
- правильно злиття враховує перейменування (наприклад, якщо файл було перейменовано лише в одній гілці)
- "git blame", (кращий) еквівалент "cvs annotate", інструмент для відображення рядкової історії вмісту файлу, може слідувати за переміщенням коду також через перейменування
Бінарні файли . CVS має лише обмежену підтримку бінарних файлів (наприклад, зображень), що вимагає від користувачів чітко позначати бінарні файли під час додавання (або пізніше за допомогою "cvs admin" або через обгортки, щоб зробити це автоматично на основі імені файлу), щоб уникнути керування двійковий файл за допомогою конверсії в кінці рядка та розширення ключових слів. Git автоматично виявляє двійковий файл на основі вмісту так само, як і CNU diff, і інші інструменти роблять це; ви можете змінити це виявлення за допомогою механізму gitattributes. Більше того, бінарні файли захищені від невідтворюваного керування завдяки умовному налаштуванню на "safecrlf" (а також тому, що потрібно запитувати перетворення в кінці рядка, хоча це може бути включено за замовчуванням залежно від розподілу), а також це (обмежене) ключове слово розширення є суворим "дозволом" в Git.
Ключове розширення . Git пропонує дуже-дуже обмежений набір ключових слів порівняно з CVS (за замовчуванням). Це пояснюється двома фактами: зміни в Git відбуваються на сховище, а не на файл, а Git уникає зміни файлів, які не змінювались при переході до іншої гілки чи перемотанні на інший момент історії. Якщо ви хочете вставити номер редакції за допомогою Git, вам слід зробити це за допомогою системи збирання, наприклад, слідуючи прикладу сценарію GIT-VERSION-GEN у джерелах ядра Linux та в джерелах Git.
Внесення змін до комісій . Оскільки в розподілених VCS, таких як акт публікації Git, є окремим від створення комісії , можна змінити (редагувати, переписати) неопубліковану частину історії, не викликаючи незручності для інших користувачів. Зокрема, якщо ви помітили помилку (або іншу помилку) у повідомленні про фіксацію або помилку у фіксації, ви можете просто використовувати "git commit --amend". Це неможливо (принаймні, не без важких хакерів) у CVS.
Більше інструментів . Git пропонує набагато більше інструментів, ніж CVS. Одним з найбільш важливих є " git bisect ", який можна використовувати для пошуку фіксації (перегляду), яка ввела помилку; якщо ваші зобов’язання невеликі та самостійні, то слід виявити, де помилка є досить простою.
Якщо ви співпрацюєте хоча б з одним іншим розробником, ви також виявите такі відмінності між Git та CVS:
Коміт перед об'єднанням Git використовує команду-перед-злиття, а не, як-от CVS, злиття-перед-фіксація (або оновлення-потім-фіксація ). Якщо під час редагування файлів, готуючись до створення нової фіксації (нової редакції), хтось інший створив нову фіксацію в тій самій гілці, і вона зараз знаходиться у сховищі, CVS змушує вас спочатку оновити робочий каталог та вирішити конфлікти, перш ніж дозволяти вам здійснювати. Це не так з Git. Ви спочатку зобов'язуєтесь, зберігаючи свій стан у контролі версій, а потім ви об'єднуєте інші зміни розробника. Ви також можете попросити іншого розробника зробити об'єднання та вирішити конфлікти.
Якщо ви віддаєте перевагу лінійній історії та уникаєте злиття, ви завжди можете скористатись робочим процесом commit-merge-повторно за допомогою "git rebase" (і "git pull --rebase"), який схожий на CVS, оскільки ви повторюєте свої зміни вгорі оновленого стану. Але ти завжди робиш перше.
Немає потреби в центральному сховищі З Git не потрібно мати єдиного центрального місця, де ви здійснюєте свої зміни. У кожного розробника може бути власне сховище (або, краще, сховища: приватне, в якому він / вона займається розробкою, і публічне оголене, де воно / він публікує ту частину, яка готова), і вони можуть витягувати / витягувати з кожного іншого сховища, в симетрична мода. З іншого боку, для більшого проекту звичайним є соціальне визначення / номінований центральний сховище, з якого всі виходять (отримують зміни).
Нарешті, Git пропонує набагато більше можливостей, коли потрібна співпраця з великою кількістю розробників. Нижче наведено відмінності між CVS у Git для різних етапів, що цікавлять та положення в проекті (під контролем версій за допомогою CVS або Git):
ховається . Якщо ви зацікавлені лише в отриманні останніх змін від проекту ( без поширення змін ) або в приватному розвитку (без участі в оригінальних проектах); або ви використовуєте закордонні проекти як основу власного проекту (зміни є локальними, і чи не має сенсу їх публікувати).
Git підтримує тут анонімний неаутентифікований доступ лише для читання за допомогою спеціального ефективного git://протоколу, або, якщо ви поза блокуванням брандмауера DEFAULT_GIT_PORT(9418), ви можете використовувати звичайний HTTP.
Для CVS найпоширенішим рішенням (наскільки я його розумію) для доступу лише для читання є обліковий запис гостя для протоколу "pserver" CVS_AUTH_PORT(2401), який зазвичай називається "анонімним" та з порожнім паролем. Вхідні дані зберігаються у $HOME/.cvspassфайлі за замовчуванням , тому їх потрібно надати лише один раз; все-таки це трохи бар'єр (ви повинні знати ім'я гостьового облікового запису або звертати увагу на повідомлення сервера CVS) і роздратування.
розробник бахроми (листник) . Один із способів розповсюдження змін в OSS - це надсилання патчів електронною поштою . Це найбільш поширене рішення, якщо ви (більш-менш) випадковий розробник, надіславши одну зміну або один виправлення. До речі. надсилання патчів може здійснюватися через дошку огляду (систему огляду патчів) або подібні засоби, не тільки електронною поштою.
Git пропонує тут інструменти, які допомагають у цьому механізмі поширення (публікації) як для відправника (клієнта), так і для сервісного сервера (сервера). Для людей, які хочуть надсилати свої зміни електронною поштою, є інструмент " git rebase " (або "git pull --rebase") для відтворення ваших власних змін поверх поточної версії за поточною версією, тому ваші зміни знаходяться поверх поточної версії (свіжі ), і " git format-patch " для створення електронної пошти з повідомленням про фіксацію (та авторство), зміною форми (розширеного) уніфікованого формату diff (плюс дифстат для легшого перегляду). Maintainer може перетворити таку електронну пошту безпосередньо на фіксацію, зберігаючи всю інформацію (включаючи повідомлення про фіксацію) за допомогою " git am ".
CVS не пропонує таких інструментів: ви можете використовувати "cvs diff" / "cvs rdiff" для генерації змін, а також використовувати патч GNU для застосування змін, але, наскільки я знаю, немає можливості автоматизувати застосування комісійного повідомлення. CVS призначений для використання у клієнтському <-> серверному режимі ...
лейтенант . Якщо ви підтримуєте окрему частину проекту (підсистеми) або якщо розвиток вашого проекту слідує за робочим процесом "мережа довіри", що використовується при розробці ядра Linux ... або просто якщо у вас є власний публічний сховище, і зміни, які ви Якщо ви хочете опублікувати занадто великі розміри, щоб надіслати електронною поштою як патч-серії , ви можете надіслати запит на тягнення до (головного) супровідника проекту.
Це рішення, характерне для систем управління розподіленими версіями, тому, звичайно, CVS не підтримує такий спосіб співпраці. Існує навіть інструмент під назвою "git request-pull", який допомагає підготувати електронну пошту для відправки в сервіс з проханням витягнути з вашого сховища. Завдяки "git bundle" ви можете використовувати цей механізм навіть не маючи публічного сховища, надсилаючи пакет змін електронною поштою або sneakernet. Деякі сайти хостингу Git, такі як GitHub, мають підтримку повідомляти про те, що хтось працює (опублікував якусь роботу) над вашим проектом (за умови, що він / вона використовує той самий сайт хостингу Git), а для PM-ing - своєрідний запит на виклик.
головний розробник , тобто той, хто безпосередньо публікує свої зміни (до основного / канонічного сховища). Ця категорія ширша для розподілених систем управління версіями, оскільки наявність декількох розробників з доступом до запису до центрального сховища є не лише можливим робочим процесом (ви можете мати єдиного технічного сервісу, який підштовхує зміни до канонічного сховища, набору лейтенантів / підтримувальних підсистем, з яких він / вона витягує та широке коло розробників листів, які надсилають патчі поштою або до списку розсилки з обслуговування або проекту, або до одного з лейтенантів / підпорядників).
У Git у вас є вибір використання протоколу SSH ( протокол git, загорнутого в SSH) для публікації змін, за допомогою таких інструментів, як "git shell" (для забезпечення безпеки, обмеження доступу до акаунтів оболонок) або Gitosis (для управління доступом, не вимагаючи окремих облікових записів оболонок ), а також HTTPS із WebDAV зі звичайною автентифікацією HTTP.
У CVS є вибір між користувацьким незашифрованим (простим текстом) протоколом pserver або використанням віддаленої оболонки (де ви дійсно повинні використовувати SSH ) для публікації змін, що для централізованої системи управління версіями означає внесення змін (створення комісій). Ну, ви також можете тунелювати протокол "pserver" за допомогою SSH, і є інструменти третіх партій, що це автоматизують ... але я не думаю, що це так просто, як, наприклад, Gitosis.
Загалом системи управління версіями, такі як Git, забезпечують набагато ширший вибір можливих робочих процесів. З централізованими системами управління версіями, такими як CVS, за необхідності вам слід розрізняти людей, які мають доступ до сховища, і тих, що не мають ... та CVS не пропонує жодних інструментів, щоб допомогти приймати внески (через патчі) від людей без зробити доступ.