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

Question

В чем разница между системами контроля версий Git и CVS?

Я с удовольствием использую CVS уже более 10 лет, и теперь мне сказали, что Git намного лучше.Не мог бы кто-нибудь, пожалуйста, объяснить, в чем разница между ними и почему один лучше другого?

Answer 1

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

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

• Настройка репозитория.Git хранит репозиторий в .git каталог в верхнем каталоге вашего проекта;CVS требуют настройки CVSROOT, центрального места для хранения информации о контроле версий для различных проектов (модулей).Следствием такого дизайна для пользователя является то, что импорт существующих исходных текстов в систему управления версиями так же прост, как "git init && git add.&& git commit" в Git, пока это более сложный в резюме.

• Атомарные операции.Поскольку CVS вначале представлял собой набор сценариев для системы контроля версий RCS для каждого файла, коммиты (и другие операции) в CVS не являются атомарными;если операция над хранилищем прерывается на середине, хранилище может быть оставлено в несогласованном состоянии.В Git все операции являются атомарными:либо они преуспевают в целом, либо терпят неудачу без каких-либо изменений.

• Наборы изменений.Изменения в CVS относятся к каждому файлу, в то время как изменения (коммиты) в Git всегда относятся ко всему проекту.Это очень важно смена парадигмы.Одним из последствий этого является то, что в Git очень легко отменить (создать изменение, которое отменяет) или undo весь изменение;другим следствием является то, что в CVS легко выполнять частичную проверку, в то время как в Git это в настоящее время практически невозможно.Тот факт, что изменения вносятся по каждому файлу, сгруппированному вместе, привел к изобретению формата Журнала изменений GNU для сообщений о фиксации в 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.

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

• Больше инструментов.Git предлагает гораздо больше инструментов, чем CVS.Одним из наиболее важных является "git разделить пополам" это можно использовать для поиска фиксации (ревизии), которая привела к ошибке;если ваши коммиты небольшие и самодостаточные, то обнаружить, где находится ошибка, должно быть довольно легко.

---

Если вы сотрудничаете хотя бы с одним другим разработчиком, вы также обнаружите следующие различия между Git и CVS:

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

  Если вы предпочитаете иметь линейную историю и избегать слияний, вы всегда можете использовать зафиксировать-объединить-подтвердить рабочий процесс через "git rebase" (и "git pull --rebase"), который похож на CVS в том смысле, что вы воспроизводите свои изменения поверх обновленного состояния.Но ты всегда берешь на себя обязательства первым.

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

---

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

• притаившийся.Если вы заинтересованы только в получении последних изменений из проекта, (нет распространения ваших изменений), или делать Частное разработка (без повторного участия в оригинальных проектах);или вы используете зарубежные проекты в качестве основы своего собственного проекта (изменения носят локальный характер, и нет смысла их публиковать).

  Git поддерживает здесь анонимный, не прошедший проверку подлинности доступ только для чтения через пользовательский интерфейс git://протокол, или если вы находитесь за блокировкой брандмауэра DEFAULT_GIT_PORT (9418) вы можете использовать обычный HTTP.

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

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

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

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

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

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

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

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

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

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

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

HTH (Надеюсь, это поможет)

Answer 2

Git - это DVCS, в отличие от централизованного CVS.Упрощенное описание будет следующим:вы получаете все преимущества контроля версий, когда вы не подключены к Любой из нескольких возможных репозиториев, плюс операции выполняются быстрее.

Answer 3

Веб-сайт Git объясняет это, вероятно, лучше всего.

Моя любимая функция - возможность выполнять коммиты в автономном режиме.И скорость, просто ошеломляющая скорость, с которой происходит все, кроме толкания и вытягивания.(И эти операции по своей конструкции неразрушающие, поэтому вы можете нажимать / тянуть, когда идете выпить кофе, если ваш центральный репозиторий задерживается.) Еще одна приятная вещь - это то, что в комплект поставки входят батарейки:встроенный gitk является достаточно хорошим средством просмотра истории; git gui является достаточно хорошим инструментом фиксации;с выходной раскраской, git add -i, git add -p, git rebase -i достаточно ли хороши интерактивные интерфейсы; git daemon и git instaweb достаточно хороши для разовой совместной работы, если вы не хотите / не можете возиться со своим центральным репозиторием.

Answer 4

Я также более 10 лет с удовольствием пользуюсь cvs, хотя мне также нравится git, и со временем я отдам предпочтение именно ему, хотя большинство проектов, над которыми я работаю в настоящее время, используют cvs или svn, и, похоже, мы не можем убедить бюрократию, где я работаю, позволить нам пробить брешь в git через брандмауэр.

Пара вещей, которые делают cvs более приятными, чем они могли бы быть в противном случае, - это cvsp, и еще одна - либо сценарии исправлений Эндрю Мортона, либо quilt.Cvsps позволяет вам объединить несколько файлов коммита в один патч (и, таким образом, извлечь "наборы изменений" из CVS), в то время как скрипты исправлений quilt или Эндрю Мортона позволяют вам довольно легко и удобно вносить разумные "наборы изменений" в cvs, позволяя вам работать над несколькими вещами одновременно, сохраняя их разделенными перед фиксацией.У CVS есть свои причуды, но я привык к большинству из них.

Answer 5

"счастливо пользоваться резюме более x лет" - интересная идея :-) Это огромный шаг вперед по сравнению с хранением большого количества копий, но ...

Я предполагаю, что вы привыкли ко всем его причудам или не слишком много занимаетесь ветвлением и слиянием.Есть и худшая возможность;

Люди в вашей организации привыкли к ограничениям в резюме, и ваша рабочая практика соответствующим образом адаптировалась;

например, никогда не заставлять более одного разработчика работать над одним пакетом одновременно, использовать ветвление только в чрезвычайных ситуациях и т.д.

Основной принцип заключается в том, что чем сложнее что-то, тем меньше людей это делают.