Ответ 1

Надежность

Если ваш жесткий диск бесшумно начинает искажать данные, вы, черт возьми, хотите знать об этом. Git принимает хэши SHA1 всего, что вы совершаете. У вас есть 1 центральный репо с SVN, и если его биты будут тихо модифицированы неисправным контроллером жесткого диска, вы не будете знать об этом, пока не опоздаете.

И поскольку у вас есть 1 центральный репо, вы просто взорвали свою единственную линию жизни.

С git каждый имеет идентичное репо, в комплекте с историей изменений, и его содержимое может быть полностью доверено из-за SHA1 его полного изображения. Поэтому, если вы создадите резервную копию своего SHAT1 на 20 байт вашего HEAD, вы можете быть уверены, что когда вы клонируете какое-то недоверенное зеркало, у вас будет то же самое репо, которое вы потеряли!

Ветвление (и загрязнение пространства имен)

Когда вы используете централизованное репо, все ветки есть для мира, чтобы видеть. Вы не можете создавать частные ветки. Вы должны создать ветку, которая еще не сталкивается с каким-либо другим глобальным именем.

"test123 - черт, там уже есть test123. Попробуем test124."

И все должны видеть все эти ветки с глупыми именами. Вы должны поддаваться политике компании, которая может идти по строкам "не делайте ветки, если вам это действительно нужно", что предотвращает множество свобод, которые вы получаете с помощью git.

То же самое с фиксацией. Когда вы совершаете, вы должны быть уверены, что ваш код работает. В противном случае вы сломаете сборку. Никаких промежуточных коммитов. Потому что все они идут на центральное репо.

С Git у вас нет этой глупости. Разделите и скопируйте локально все, что хотите. Когда вы будете готовы подвергать свои изменения всему остальному миру, вы просите их отстраниться от вас или вы нажмете его на какой-то "основной" Git репо.

Производительность

Поскольку ваше репо является локальным, все операции VCS бывают быстрыми и не требуют круговых поездок и передачи с центрального сервера! git log не нужно переходить через сеть, чтобы найти историю изменений. SVN делает. То же самое со всеми другими командами, так как все важные вещи хранятся в одном месте!

Смотрите разговор Linus для этих и других преимуществ по сравнению с SVN.

Ответ 2

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

До тех пор, пока я не набрал git init и не нашел себя внутри репозитория git.

Я предлагаю вам сделать то же самое - просто попробуйте. Начните с небольшого хобби проекта, просто чтобы повесить его. Затем решите, стоит ли использовать что-то большее.

Ответ 3

Я Mercurial разработчик и работал консультантом Mercurial. Поэтому я нахожу ваши вопросы очень интересными и надеюсь, что я им отвечу:

• В чем преимущество или ценность совершения локально? [...]

Вы правы, что IDE могут отслеживать локальные изменения, помимо простого отмены/повтора в эти дни. Тем не менее, все еще есть недостаток в функциональности между этими моментальными снимками файлов и полной системой управления версиями.

Локальные коммиты дают вам возможность подготовить свою "историю" локально, прежде чем отправлять ее на рассмотрение. Я часто работаю над некоторыми изменениями, включающими 2-5 коммитов. После того, как я совершу фиксацию 4, я мог бы вернуться и немного изменить фиксацию 2 (возможно, я видел ошибку в фиксации 2 после того, как сделал commit 4). Таким образом, я буду работать не только по последнему коду, но и по последним парам. Это тривиально возможно, когда все локально, но становится более сложным, если вам нужно синхронизировать с центральным сервером.

• что, если я разбиваю свой жесткий диск? [...], так как это круто по сравнению с проверкой центрального репо?

Не круто!: -)

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

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

Изменения часто остаются нерегулярными, потому что:

• Они на самом деле не закончены. В коде могут быть отладочные заявления печати, могут быть неполные функции и т.д.

• Committing войдет в trunk, и это опасно для централизованной системы, поскольку оно влияет на всех остальных.

• Для фиксации требуется сначала слияние с центральным хранилищем. Это слияние может быть пугающим, если вы знаете, что были внесены другие противоречивые изменения в код. Слияние может просто быть раздражающим, потому что вы не можете все сделать с изменениями, и вы предпочитаете работать в хорошо известном состоянии.

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

Вы абсолютный правильный, если считаете, что это не вопрос централизованного и распределенного контроля версий. С помощью CVCS люди могут работать в отдельных ветвях и таким образом тривиально избегать 2 и 3 выше. С отдельной ветвью отбрасывания я также могу зафиксировать столько, сколько захочу, так как я могу создать другую ветку, где я совершу более полированные изменения (решение 1). Однако фиксации могут быть медленными, поэтому 4 могут применяться еще.

Люди, которые используют DVCS, часто будут нажимать свои локальные коммиты на удаленный сервер в любом случае в качестве решения для резервного копирования для бедных. Они не нажимают на главный сервер, где работает остальная часть команды, а на другой (возможно, частный) сервер. Таким образом, они могут работать изолированно и по-прежнему сохранять резервные копии вне сайта.

• Работа в автономном режиме или в воздушной плоскости. [...]

Да, мне тоже не нравился этот аргумент. Я имею хорошее подключение к Интернету в 99% случаев и не летаю достаточно, чтобы это было проблемой: -)

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

Инструменты DVCS разработаны вокруг идеи, что люди могут работать в автономном режиме. Это имеет ряд важных последствий:

• Слияние ветвей становится естественным. Когда люди могут работать параллельно, вилки будут, естественно, встречаться в графе фиксации. Поэтому эти инструменты должны быть действительно хорошими при слиянии веток. Инструмент такой SVN не очень хорош в слиянии!

  Git, Mercurial и другие инструменты DVCS сливаются лучше, потому что у них было больше испытаний в этой области, а не напрямую, потому что они распределены.

• Больше гибкости. С помощью DVCS у вас есть свобода выталкивать/вытягивать изменения между произвольными репозиториями. Я часто буду нажимать/тянуть между домашними и рабочими компьютерами без использования какого-либо реального центрального сервера. Когда все готово к публикации, я подталкиваю их к месту, как Битбукет.

  Многосайтовая синхронизация больше не является "корпоративной функцией", это встроенная функция. Поэтому, если у вас есть оффшорное местоположение, они могут настроить локальный репозиторий концентратора и использовать это между собой. Затем вы можете синхронизировать локальные хабы, ежедневно или когда это вам подходит. Для этого требуется не больше, чем cronjob, выполняющий регулярные интервалы hg pull или git fetch.

• Улучшенная масштабируемость, поскольку на стороне клиента больше логики. Это означает меньший объем обслуживания на центральном сервере и более мощные клиентские инструменты.

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

Ответ 4

DVCS очень интересен для меня, поскольку он:

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

  • жизненный цикл разработки (с репозиториями, созданными только для определенного типа коммитов, например, тот, который был выпущен в профили, для целей развертывания)
  • Индивидуальные задачи (вы можете нажать и обновить резервное репо, даже в форме всего одного файла)
  • проект взаимозависимостей (когда команда проекта A ждет командного пилота B, чтобы, наконец, совершить центральное репо, может попросить B "передать" промежуточную разработку в виде прикрепленного почтового файла в почте. Теперь все, что нужно сделать A, это добавить B repo в качестве потенциального пульта, получить его и заглянуть в него.

• добавляет новый способ создания/потребления версий с помощью

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

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

Ответ 5

Ваш главный аргумент в отношении IDE, выполняющий отслеживание для вас, является ложным. Большинство IDE на самом деле не имеют такой функциональности, кроме неограниченных уровней отмены. Подумайте о ветвях, слияниях, ревертах, фиксации сообщений (журналов) и тому подобных, и я уверен, что даже IDE, о которой вы говорили, не соответствует требованиям. Особенно я сомневаюсь, что это отслеживание ваших коммитов - возможно, на нескольких разных ветвях, над которыми вы работаете, - и правильное нажатие их в репозиторий после того, как вы выйдете в Интернет.

Если ваша IDE на самом деле все это делает, я бы назвал ее распределенной системой управления версиями сам по себе.

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

EDIT: вы можете использовать DVCS так же, как и централизованный репозиторий, и я бы даже рекомендовал сделать это для проектов малого и среднего размера. Наличие одного центрального "авторитетного" репозитория, который всегда в сети, упрощает многое. И когда эта машина выйдет из строя, вы можете временно переключиться на одну из других машин, пока сервер не будет исправлен.

Ответ 6

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

Особенности IDE ограничены и неуклюжи. Они не похожи на полную функцию.

Один хороший пример того, как этот материал используется, - это различные проекты Apache. Я могу синхронизировать репозиторий git с репозиторией Apache svn. Тогда я могу работать неделю в частной ветке, все мои собственные. Я могу сбрасывать изменения с репо. Я могу сообщить о своих изменениях, розничной или оптовой продаже. И когда я закончил, я могу упаковать их как одну фиксацию.

Ответ 7

Интересный вопрос.

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

Мне нравится быть способным к 2-шаговой фиксации. Меня это устраивает.

Некоторые преимущества, которые spring уму:

• Улучшенная поддержка слияния. Branch-Merge чувствует себя больше как гражданин 1-го класса в DVCS, тогда как по моему опыту централизованных решений я обнаружил, что это болезненно и сложно. Слияние отслеживания теперь доступно в svn, но оно все еще медленное и громоздкое.

• Большие команды. DVCS предназначен не только для однопользовательских транзакций. Вы можете нажать и вытащить фиксации между командами, прежде чем вносить свой вклад в мастер-репозиторий (или нет). Это неоценимо для некоторых разновидностей сотрудничества.

• при работе над экспериментальной функциональностью имеет смысл совершать часто, но только для краткосрочных. Я не хочу всегда разворачивать основную кодовую базу, поэтому приятно играть и перезаписывать. Точно так же я вижу, что это полезно при работе с Continuous Integration. Если я много дней работаю над рефакторингом, я могу сломать сборки для неприемлемого таймфрейма, но я все равно хочу отслеживать свои изменения.

Обратите внимание, что мой опыт DVCS больше связан с Mercurial, чем с Git. Исходя из фона CVS/SVN, я нашел кривую обучения намного проще с Mercurial (Hg). Недавно добавленная поддержка Google Code для Mercurial также является благом. ... Я даже догадываюсь, что мой первоначальный ответ на Git был отрицательным, но больше с точки зрения удобства использования, чем с DVCS

Ответ 8

Интересно отметить, что Subversion, вероятно, будет получать в будущем такие вещи, как offline commit. Конечно, мы не можем сравнить эти функции с тем, что доступно сегодня, но это может быть очень хороший способ "использовать DVCS централизованным образом", как описано в других ответах здесь.

Другой недавний пост утверждает, что Subversion не пытается стать DVCS

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

Ответ 9

Я ничего не буду продавать здесь.

• В чем преимущество или ценность совершения локально? Какие? действительно? Все современные IDE позволяют отслеживать изменения? и если требуется, чтобы вы могли восстановить определенные изменения. Кроме того, у них есть чтобы обозначить ваши изменения/версии на уровне IDE!?

Единственное реальное преимущество заключается в том, что вам не нужно подключаться к основному центральному репозиторию. Кто-то может сказать, что преимущество Git заключается в том, что разработчик может совершать локально, готовя отличную комбинацию патчей, а затем тянет их к благословленному центральному репо, но ИМО это довольно неинтересно. Разработчик может использовать приватную полку или ветку в репозитории Subversion для работы над своей задачей, а затем объединить ее с основной линией (например,/trunk) или другой веткой.

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

Другой недостаток централизации заключается в том, что Git технически не может отслеживать переименования или операции копирования. Это просто пытается угадать, был ли файл переименован или скопирован на основе содержимого файла. Это приводит к таким забавным случаям: svn to Git миграция, сохраняющая историю скопированного файла (Гай спрашивает, почему история файла была потеряна после SVN > Git миграция,).

• Что делать, если я разбиваю жесткий диск? где мой локальный репозиторий? (так как это круто по сравнению с проверкой центрального репо?)

С Git, если вы разбили свое локальное запоминающее устройство (HDD, SSD, что угодно), и у него были изменения, которые не были вытащены или переброшены в блаженный репо Git, тогда вам не повезло. Вы просто потеряли время и свой код. В дополнение к этому, сбой на жестком диске с локальным репозиторией Git может приостановить процесс разработки в течение некоторого времени: Линус Torvald SSD прерывает, останавливает ядро ​​Linux развитие.

С централизованным контролем источника, таким как SVN, вы можете потерять только свой последний коммит, потому что вся ваша работа была уже привязана к центральному репозиторию к ветке, закрытой полке или даже к багажнику. Очевидно, что вы должны убедиться, что для вашего центрального репо было выполнено аварийное восстановление и резервное копирование.

• Окей Линус Торвальдс отдает свою жизнь Git и ненавидит все остальное. Достаточно ли этого, чтобы слепо похвалить? Линус живет в другом мир по сравнению с оффшорными разработчиками в моем проекте среднего размера?

Для такого проекта, как Linux Kernel, который использовал BitKeeper в прошлом, Git - лучшая система управления версиями! Но я бы сказал, что Git не подходит всем.

Выберите разумно!

Ответ 10

Скорее всего, никто ничего вам не продаст. Если вам нужны функции git, просто git init. Если это не подходит для вас, просто не делайте этого.

Если вы еще не знаете функции git, введите git vs (обратите внимание на конечное пространство) в поиске Google и просмотрите результаты автозаполнения.

Я предпочел Блокнот над IDE, пока мне не нужны функции Netbeans. Кажется, что здесь один и тот же случай.

Как вы знаете, было много успешных проектов без VCS вообще.

PS. Продажа git нарушает его лицензию!;)