Продай мне распределенный контроль версий

Я знаю тысячи подобных тем, плавающих вокруг. Я читаю по крайней мере 5 тем здесь в SO. Но почему я все еще не убежден в DVCS?

У меня есть только следующие вопросы (обратите внимание, что я эгоистично беспокоюсь только о проектах Java)

  • В чем преимущество или ценность совершения локально? Какие? действительно? Все современные IDE позволяют отслеживать ваши изменения? и при необходимости вы можете восстановить конкретное изменение. Кроме того, у них есть возможность пометить ваши изменения / версии на уровне IDE!?
  • что если я сломаю жесткий диск? Куда ушел мой локальный репозиторий? (так как это круто по сравнению с регистрацией в центральном репо?)
  • Работа в автономном режиме или в самолете. Что в этом такого? Для того, чтобы создать релиз с моими изменениями, я должен в конечном итоге подключиться к центральному репозиторию. До этого не имеет значения, как я отслеживаю свои изменения локально.
  • Хорошо, Линус Торвальдс отдает свою жизнь Гиту и ненавидит все остальное. Этого достаточно, чтобы слепо петь хвалу? Линус живет в другом мире по сравнению с оффшорными разработчиками в моем проекте среднего размера?

Брось меня!

Источник

10 ответов

Решение

надежность

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

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

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

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

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

" test123 - блин, уже есть test123, Давай попробуем test124 ".

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

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

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

Спектакль

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

Посмотрите доклад Линуса об этих и других преимуществах по сравнению с SVN.

Источник

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

Пока, однажды, я не набрал git init и внезапно оказался в хранилище git.

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

Источник

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

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

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

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

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

Не круто на всех!:-)

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

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

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

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

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

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

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

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

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

  • Работа в автономном режиме или в самолете. [...]

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

Источник

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

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

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

РЕДАКТИРОВАТЬ: Вы можете использовать DVCS так же, как централизованное хранилище, и я бы даже рекомендовал делать это для проектов малого и среднего размера по крайней мере. Наличие одного центрального "авторитетного" хранилища, которое всегда подключено к сети, упрощает многое. И когда эта машина выходит из строя, вы можете временно переключиться на одну из других машин, пока сервер не будет исправлен.

Источник

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

Выбирать мудро!

Источник

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

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

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

Источник

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

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

Мне нравится возможность двухэтапного коммита. Меня это устраивает.

Некоторые преимущества, которые приходят на ум:

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

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

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

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

Источник

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

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

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

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

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

Источник
Другие вопросы по тегам