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

Ответ 1

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

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

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

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

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

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

  Если вы предпочитаете иметь линейную историю и избегать слияний, вы всегда можете использовать work-merge-reinit workflow через "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) и раздражение.

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

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

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

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

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

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

  С Git у вас есть выбор использования протокола SSH (git, завернутого в SSH), чтобы публиковать изменения с помощью таких инструментов, как "git shell" (для обеспечения безопасности, ограничения доступ к учетным записям оболочки) или Создание программного обеспечения с открытым исходным кодом в разделе об управлении версиями говорится, что лучше не предоставлять слишком строгие, жесткие и строгие меры контроля в тех областях, где разрешено вносить изменения в публичный репозиторий; гораздо лучше полагаться (на это) на социальные ограничения (например, обзор кода), чем на технические ограничения; распределенные системы управления версиями уменьшают ИМХО еще дальше...

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

Ответ 2

Этот разговор Линуса (автор оригинала git) в значительной степени суммирует его.

Google Tech Talks: Линус Торвальдс на Git

Внимание: очень упрямый разговор.

Ответ 3

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

Ответ 4

Веб-сайт Git объясняет это наилучшим образом.

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

Ответ 5

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

Несколько вещей, которые делают cvs лучше, чем в противном случае, это cvsps, а другой - скрипты патча Andrew Morton или одеяло. Cvsps позволяет вам восстанавливать несколько файлов фиксации в одном патче (и, таким образом, извлекать "изменения" из CVS), в то время как quilt, или скрипты исправления Andrew Morton позволяют вам легко и комфортно фиксировать "changeets" в cvs, что позволяет работайте над mutliple вещи одновременно, все еще сохраняя их разделенные до совершения. CVS имеет свои причуды, но я привык к большинству из них.

Ответ 6

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

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

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

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

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