Основное отличие состоит в том, что (как уже было сказано в других ответах) 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 branchname ") ... это было необходимо, потому что распределенная разработка естественным образом ведет к нескольким ветвям.
Это означает, что вы можете использовать тематические ветки , т. Е. Разрабатывать отдельную функцию в несколько этапов в отдельной ветке функций.
Переименовать (и скопировать) трекинг . Переименование файлов не поддерживается в CVS, а ручное переименование может разбить историю на две части или привести к неверной истории, когда вы не сможете правильно восстановить состояние проекта перед переименованием. Git использует эвристическое определение переименования, основанное на сходстве содержимого и имени файла (это решение хорошо работает на практике). Вы также можете запросить обнаружение копирования файлов. Это означает, что:
- при просмотре указанного коммита вы получите информацию о том, что какой-то файл был переименован,
- при правильном слиянии учитываются переименования (например, если файл был переименован только в одной ветке)
- "git blame", (лучший) эквивалент "cvs annotate", инструмента для отображения построчной истории содержимого файла, может отслеживать перемещение кода также при переименовании
Двоичные файлы . CVS имеет очень ограниченную поддержку двоичных файлов (например, изображений), требуя, чтобы пользователи явно помечали двоичные файлы при добавлении (или позже с помощью "cvs admin" или через оболочки, чтобы сделать это автоматически на основе имени файла), чтобы избежать искажения двоичный файл с помощью преобразования конца строки и расширения ключевых слов. Git автоматически определяет двоичный файл на основе содержимого точно так же, как это делают CNU diff и другие инструменты; вы можете переопределить это обнаружение с помощью механизма gitattributes. Более того, бинарные файлы защищены от невосстановимого искажения благодаря по умолчанию 'safecrlf' (и тому факту, что вам нужно запрашивать преобразование конца строки, хотя это может быть включено по умолчанию в зависимости от распределения) и этому ключевому слову (limited) расширение - это строгое согласие в 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 дело обстоит иначе. Сначала вы делаете коммит, сохраняя свое состояние в системе управления версиями, а затем объединяете другие изменения разработчика. Вы также можете попросить другого разработчика выполнить слияние и разрешить конфликты.
Если вы предпочитаете иметь линейную историю и избегать слияний, вы всегда можете использовать рабочий процесс фиксация-слияние-повторение через «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 предлагает здесь инструменты, которые помогают в этом механизме распространения (публикации) как для отправителя (клиента), так и для сопровождающего (сервера). Для людей , которые хотят отправить свои изменения по электронной почте есть « мерзавец перебазироваться » (или «мерзавец тянуть --rebase») инструмента для воспроизведения собственных изменений поверх текущей версии вверх по течению, так что ваши изменения поверх текущей версии (свежие ) и « git format-patch » для создания электронного письма с сообщением о фиксации (и авторством), изменение в форме (расширенного) унифицированного формата сравнения (плюс diffstat для упрощения просмотра). Сопровождающий может превратить такое электронное письмо напрямую в фиксацию, сохранив всю информацию (включая сообщение фиксации), используя « git am ».
CVS не предлагает таких инструментов: вы можете использовать "cvs diff" / "cvs rdiff" для генерации изменений и использовать патч GNU для применения изменений, но, насколько мне известно, нет способа автоматизировать применение сообщения о фиксации. CVS предназначалась для использования в режиме клиент <-> сервер ...
лейтенант . Если вы сопровождаете отдельную часть проекта (подсистему), или если ваш проект разрабатывается в соответствии с рабочим процессом «сети доверия», используемым при разработке ядра Linux ... или если у вас есть собственный публичный репозиторий, и вы меняете хотите опубликовать, слишком велики для отправки по электронной почте в виде серии патчей , вы можете отправить запрос на перенос (основному) сопровождающему проекта.
Это решение, специфичное для распределенных систем контроля версий, поэтому, конечно же, CVS не поддерживает такой способ сотрудничества. Существует даже инструмент под названием «git request-pull», который помогает подготовить электронное письмо для отправки сопровождающему с запросом на извлечение из вашего репозитория. Благодаря «git bundle» вы можете использовать этот механизм даже без общедоступного репозитория, отправив пакет изменений по электронной почте или через sneakernet. Некоторые хостинговые сайты Git, такие как GitHub , поддерживают уведомление о том, что кто-то работает (опубликовал некоторую работу) над вашим проектом (при условии, что он / она использует тот же сайт хостинга Git), а также для PM-ing своего рода pull request.
основной разработчик , т.е. тот, кто напрямую публикует свои изменения (в основной / канонический репозиторий). Эта категория шире для распределенных систем управления версий, как имеющие несколько разработчиков с доступом к записи в центральное хранилище не только возможно , рабочий процесс (вы можете иметь одного сопровождающие , который проталкивает изменения в каноническое хранилище, набор лейтенантов / подсистемы сопровождающие , из которой он / она pulls, а также широкий круг конечных разработчиков, которые отправляют исправления по почте либо в список рассылки сопровождающего / проекта, либо одному из лейтенантов / субмейнтейнеров).
С Git у вас есть выбор использовать протокол SSH ( протокол git, завернутый в SSH) для публикации изменений с такими инструментами, как «git shell» (для обеспечения безопасности, ограничение доступа учетных записей оболочки) или Gitosis (для управления доступом без необходимости отдельных учетных записей оболочки. ) и HTTPS с WebDAV с обычной HTTP-аутентификацией.
В CVS есть выбор между настраиваемым незашифрованным (обычным текстом) протоколом pserver или использованием удаленной оболочки (где вам действительно следует использовать SSH ) для публикации ваших изменений, что для централизованной системы контроля версий означает фиксацию ваших изменений (создание коммитов). Ну, вы также можете туннелировать протокол «pserver», используя SSH, и есть сторонние инструменты, автоматизирующие это ... но я не думаю, что это так просто, как, например, Gitosis.
В целом распределенные системы контроля версий, такие как Git, предоставляют гораздо более широкий выбор возможных рабочих процессов. В централизованных системах контроля версий, таких как CVS, по необходимости вы должны различать людей с доступом к репозиторию для фиксации и тех, у кого нет ... и CVS не предлагает никаких инструментов, помогающих принимать взносы (через патчи) от людей без зафиксировать доступ.