Основное отличие состоит в том, что (как уже было сказано в других ответах) CVS - это (старая) централизованная система управления версиями, а Git распространяется.
Но даже если вы используете контроль версий для одного разработчика на одной машине (одной учетной записи), между Git и CVS есть несколько отличий:
Настройка хранилища . Git хранит репозиторий в каталоге .git в верхнем каталоге вашего проекта; CVS требует настройки CVSROOT, центральное место для хранения информации контроля версий для различных проектов (модулей). Следствием этого дизайна для пользователя является то, что импортировать существующие источники в систему управления версиями так же просто, как «git init && git add. && git commit» в Git, тогда как это более сложно в CVS.
Атомные операции . Поскольку CVS в начале был набором скриптов для системы контроля версий RCS для каждого файла, коммиты (и другие операции) не являются атомарными в CVS; если операция с хранилищем прерывается в середине, хранилище может остаться в несогласованном состоянии. В Git все операции являются атомарными: либо они завершаются успешно, либо завершаются неудачей без каких-либо изменений.
* Изменения 1023 *. Изменения в 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 branchname ») ... это нужно было, потому что распределенная разработка естественным образом ведет к нескольким ветвям.
Это означает, что вы можете использовать тематических веток , то есть разработать отдельную функцию в несколько этапов в отдельной ветке функций.
Переименование (и копирование) отслеживания . Переименования файлов не поддерживаются в 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 act , публикация отделена от создания коммита, можно изменять (редактировать, переписывать) неопубликованную часть истории, не причиняя неудобств другим пользователям. В частности, если вы заметили опечатку (или другую ошибку) в сообщении коммита или ошибку в коммите, вы можете просто использовать «git commit --amend». Это невозможно (по крайней мере, без тяжелой хакерской атаки) в CVS.
Дополнительные инструменты . Git предлагает гораздо больше инструментов, чем CVS. Одним из наиболее важных является " git bisect ", который можно использовать для поиска коммита (ревизии), в котором была обнаружена ошибка; если ваши коммиты малы и самодостаточны, выяснить, где ошибка, будет довольно легко.
Если вы сотрудничаете хотя бы с одним другим разработчиком, вы также найдете следующие различия между Git и CVS:
Коммит до слияния Git использует commit-before-merge вместо, как, например, CVS, merge-before-commit (или обновить, затем фиксации ). Если, когда вы редактировали файлы, готовясь к созданию нового коммита (новой ревизии), кто-то другой создал новый коммит в той же ветке, и теперь он находится в репозитории, CVS заставит вас сначала обновить ваш рабочий каталог и разрешить конфликты, прежде чем разрешить вам коммит. Это не относится к Git. Сначала вы фиксируете, сохраняя свое состояние в управлении версиями, затем объединяете другие изменения разработчика. Вы также можете попросить другого разработчика выполнить слияние и разрешить конфликты.
Если вы предпочитаете иметь линейную историю и избегать слияний, вы всегда можете использовать рабочий процесс commit-merge-Recommit через "git rebase" (и "git pull --rebase"), который похож на CVS в том, что вы воспроизводите свои изменения поверх обновленного состояния. Но вы всегда делаете коммит первым.
Нет необходимости в центральном хранилище С Git нет необходимости иметь единственное центральное место, где вы фиксируете свои изменения. Каждый разработчик может иметь свой собственный репозиторий (или лучший репозиторий: частный, в котором он / она занимается разработкой, и общедоступный, где он / он публикует ту часть, которая готова), и они могут извлекать / извлекать друг из друга репозитории, в симметричная мода. С другой стороны, для более крупного проекта характерно иметь социально определенный / назначенный центральный репозиторий, из которого все извлекают (получают изменения).
Наконец, Git предлагает гораздо больше возможностей, когда необходимо сотрудничество с большим количеством разработчиков. Ниже приведены различия между CVS в Git для разных стадий интереса и позиции в проекте (под контролем версий с использованием CVS или Git):
Lurker . Если вы заинтересованы только в получении последних изменений из проекта ( без распространения ваших изменений ) или в приватной разработке (без участия в первоначальных проектах); или вы используете иностранные проекты в качестве основы вашего собственного проекта (изменения являются локальными и нет смысла их публиковать).
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 (плюс diffstat для более удобного просмотра) , Сопровождающий может превратить такую электронную почту непосредственно в коммит, сохраняя всю информацию (включая сообщение о коммите), используя " git am ".
CVS не предлагает таких инструментов: вы можете использовать "cvs diff" / "cvs rdiff" для генерации изменений и использовать патч GNU для применения изменений, но, насколько я знаю, нет способа автоматизировать применение сообщения коммита. CVS предназначался для использования в клиентской <-> серверной моде ...
лейтенант . Если вы являетесь сопровождающим отдельной части проекта (подсистемы), или если разработка вашего проекта следует рабочему процессу «сеть доверия», используемому при разработке ядра Linux ... или просто если у вас есть свой общедоступный репозиторий, и изменения, которые вы если вы хотите опубликовать слишком большие файлы для отправки по электронной почте как серия исправлений , вы можете отправить запрос на извлечение (главному) сопровождающему проекта.
Это решение относится только к распределенным системам контроля версий, поэтому, конечно, CVS не поддерживает такой способ сотрудничества. Существует даже инструмент под названием «git request-pull», который помогает подготовить электронную почту для отправки сопровождающему с запросом на получение из вашего хранилища. Благодаря «git bundle» вы можете использовать этот механизм, даже не имея публичного репозитория, отправляя пакет изменений по электронной почте или через sneakernet. Некоторые сайты хостинга Git, такие как GitHub , имеют поддержку для уведомления о том, что кто-то работает (опубликовал какую-то работу) над вашим проектом (при условии, что он / она использует тот же сайт хостинга Git), а также для PM-типа. запроса на выдачу.
основной разработчик , то есть тот, кто напрямую публикует свои изменения (в основном / каноническом хранилище). Эта категория шире для распределенных систем управления версиями, поскольку наличие нескольких разработчиков с доступом для записи к центральному репозиторию - не только возможный рабочий процесс (у вас может быть один сопровождающий, который толкает изменения в каноническом репозитории, набор лейтенантов / сопровождающих подсистем, из которых он / она извлекает, и широкий круг конечных разработчиков, которые отправляют исправления по почте либо в список рассылки сопровождающего / проекта, либо одному из лейтенантов / подчиненных).
С Git вы можете использовать протокол SSH (протокол git, заключенный в SSH) для публикации изменений с помощью таких инструментов, как "git shell" (для обеспечения безопасности, ограничения доступа к учетным записям оболочки) или Gitosis (для управления доступом без использования отдельных учетных записей оболочки) и HTTPS с WebDAV с обычной аутентификацией HTTP.
В CVS есть выбор между пользовательским незашифрованным (простой текст) pserver протоколом или использованием удаленной оболочки (где вам действительно следует использовать SSH ) для публикации ваших изменений, что для централизованной системы контроля версий означает фиксацию ваших изменений (создание коммитов). Ну, вы также можете туннелировать протокол 'pserver', используя SSH, и есть сторонние инструменты, автоматизирующие это ... но я не думаю, что это так просто, как, например, Gitosis.
В целом распределенные системы контроля версий, такие как Git, предоставляют гораздо более широкий выбор возможных рабочих процессов. В централизованных системах контроля версий, таких как CVS, по необходимости вы должны различать людей с доступом к репозиторию и тех, у кого нет ... и CVS не предлагает никаких инструментов, помогающих принимать вклады (с помощью исправлений) от людей без совершить доступ.