Разница между GIT и CVS

основное отличие заключается в том, что (как уже было сказано в других ответах) 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" (и тот факт, что вам нужно запросить конец строки преобразование, хотя это может быть включено по умолчанию в зависимости от распределения), и это (ограниченное) расширение ключевого слова является строгим "выбором" в Git.

• расширение ключевых слов. Git предлагает очень ограниченный набор ключевых слов по сравнению с CVS (по умолчанию). Это связано с двумя фактами: изменения в Git относятся к репозиторию, а не к файлу, и Git избегает изменения файлов, которые не изменились при переключении на другую ветвь или перемотке в другую точку история. Если вы хотите внедрить номер версии с помощью Git, вы должны сделать это с помощью своей системы сборки, например, следуя примеру сценария GIT-VERSION-GEN в источниках ядра Linux и в источниках Git.

• О внесении изменений совершает. Потому что в распределенных VCS, таких как Git act of публикации отделен от создания фиксации, можно изменить (редактировать, переписывать) неопубликованную часть истории без неудобств для других пользователей. В частности, если вы заметили опечатка (или другая ошибка) в сообщении о фиксации или ошибка в фиксации, вы можете просто использовать "git commit --amend". Это невозможно (по крайней мере, не без тяжелого хакерства) в CVS.

• протокол, или если вы находитесь за фаерволлом блокировку DEFAULT_GIT_PORT (9418) вы можете использовать простой HTTP.

  для CVS наиболее распространенным решением (как я понимаю) для доступа только для чтения является учетная запись "гость" для протокола "pserver" на CVS_AUTH_PORT (2401), обычно называемый "анонимный" и с пустым паролем. Полномочия хранятся по умолчанию в $HOME/.cvspass файл, поэтому вы должны предоставить его только один раз; тем не менее, это немного барьер (вы должны знать имя гостевой учетной записи или обратить внимание на сообщения сервера CVS) и раздражение.

• fringe developer (Leaf contributor). Один из способов распространения ваших изменений в OSS -отправка патчей по электронной почте. Это наиболее распространенное решение, если вы (более или менее) случайный разработчик, отправляющий одно изменение или один исправление ошибки. КСТАТИ. отправка патчей может быть через обзорную доску (patch review system) или аналогичные средства, а не только по электронной почте.

  Git предлагает здесь инструменты, которые помогают в этом механизме распространения (публикации) как для отправителя (клиента), так и для сопровождающего (сервера). Для людей, которые хотят отправить их по электронной почте есть " git rebase" (или "git pull --rebase") инструмент для воспроизведения собственных изменений поверх текущей версии вверх по течению, поэтому ваши изменения находятся поверх текущей версии (являются свежий), и " git format-patch " чтобы создать электронную почту с сообщением о фиксации (и авторством), измените в виде (расширенного) унифицированного формата diff (плюс diffstat для облегчения просмотра). Сопровождающий может превратить такую электронную почту непосредственно в фиксацию, сохраняя всю информацию (включая сообщение фиксации) с помощью "git am".

  CVS не предлагает таких инструментов: вы можете использовать "cvs diff" / "cvs rdiff" для генерации изменений и использовать патч GNU для применения изменений, но, насколько я знаю, есть нет способа автоматизировать применение сообщения фиксации. CVS предназначался для использования в клиентской серверной моде...

• лейтенант. Если вы являетесь сопровождающим отдельной части проекта (подсистемы), или если разработка вашего проекта следует за рабочим процессом "сеть доверия", используемым в разработке ядра Linux... или просто если у вас есть свой репозиторий, и изменения, которые вы хотите опубликовать, слишком большие для отправки по электронной почте в виде серии патч, вы можно отправить pull-запрос к (главному) сопровождающему проекта.

  это решение для распределенные системы управления версиями, поэтому, конечно, CVS не поддерживает такой способ сотрудничества. Существует даже инструмент под названием "git request-pull", который помогает подготовить электронную почту для отправки сопровождающему с просьбой вытащить из вашего репозитория. Благодаря "git bundle" вы можете использовать этот механизм даже без публичного репозитория, отправив пакет изменений через электронной почте или, скорее. Некоторые из Git хостинг сайтов, таких как GitHub есть поддержка для уведомления о том, что кто-то работает (опубликовал какую-то работу) на вашем проекте (при условии, что он/она использует тот же сайт хостинга Git), и для PM-ING своего рода запрос на вытягивание.

• главный разработчик, то есть кто-то, кто напрямую публиковать его / ее изменения (в основной/канонический репозиторий). Эта категория является более широкой для распределенных систем управления версиями, поскольку наличие нескольких разработчиков с доступом на запись в центральный репозиторий-это не только возможный рабочий процесс (у вас может быть один сопровождающий, который запихивает изменения в каноническом репозитории, набор помощников / сопровождающих подсистемы, из которых он/она вытаскивает, и широкий спектр листовых разработчиков, которые отправляют патчи по почте либо в список рассылки сопровождающего/проекта, либо в один из помощников/подчиненных).

  С Git, у вас есть выбор, используя SSH протокол (протокол git, завернутый в SSH) для публикации изменений с помощью таких инструментов, как "Git shell" (для обеспечения безопасности, ограничения доступа к учетным записям оболочки) или gitosis'а (для управления доступом, не требуя отдельных учетных записей оболочки), и HTTPS С WebDAV, с обычной аутентификацией HTTP.

  С CVS есть выбор между custom незашифрованном виде (обычный текст) pserver протокол, или с помощью удаленной оболочки (где вы действительно должны использовать SSH) опубликовать ваши изменения, которые для централизованный система контроля версий означает фиксацию изменений (создание коммитов). Ну, вы также можете туннелировать протокол "pserver" с помощью SSH, и есть свои партийные инструменты, автоматизирующие это... но я не думаю, что это так легко, как например, gitosis'а.

в целом распределенные системы управления версиями, такие как Git, обеспечивают гораздо более широкий выбор возможных рабочих процессов. С централизованными системами управления версиями, такими как CVS, по необходимости вы должны различать людей с фиксированным доступом к репозиторию и тех, кто без него... и CVS не предлагает никаких инструментов, чтобы помочь с принятием вкладов (через патчи) от людей без фиксации доступа.

Карл Фогель в Производство Программного Обеспечения С Открытым Исходным Кодом в разделе О контроле версий говорится, что лучше не предоставлять слишком строгий, жесткий и строгий контроль над областями, где он есть разрешено вносить изменения в публичный репозиторий; гораздо лучше полагаться (для этого) на социальные ограничения (такие как обзор кода), чем на технические ограничения; распределенные системы контроля версий еще больше уменьшают это IMHO...

HTH (Надеюсь, Что Это Поможет)