Почему мне не нужен центральный репозиторий в управлении версиями? Вопрос SVN против Git

Ответ 1

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

Истина заключается в том, что вы можете, и, скорее всего, настроить свою систему Git на наличие единственного "мастера". Что отличается от Git, так это то, что каждый "рабочий каталог" также получает свой собственный клиентский репозиторий. Большое количество дизайна Git предназначено для объединения кода между клиентскими репозиториями и родителем.

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

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

Ответ 2

Точка DVCS не "избегает центрального репозитория". Большинство проектов на основе DVCS, которые я вижу, имеют некоторое представление об общем уровне HEAD - люди нажимают патчи на эту HEAD и что там, где выпуски происходят.

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

• Удобство. Если я добавлю новую функцию, я могу ее зафиксировать - и у вас будет хорошая запись рабочей версии кода - без какой-либо сетевой поддержки или для того, чтобы засунуть мой, возможно, сломанный код, в руки других людей.
• Контроль параллельной разработки. Полностью независимо я могу работать с одним набором функций и использовать управление версиями всеми способами, которые, как мы знаем, улучшают работу, в то время как кто-то другой может совершать патчи с одним и тем же кодом (чтобы они могли использовать контроль над версиями), не мешая моя разработка
• Ветвление, слияние и т.п. DVCSes имеют гораздо лучшую поддержку - поскольку это неотъемлемая идея в распределенной системе - для ветвления. Если мне не нравится то, что делает руководитель проекта, тривиальный для меня, чтобы разветкить проект. Я вытаскиваю HEAD, начинаю заниматься этим репо и могу отправить это репо всем, кто хочет мою ветку. Аналогичным образом, в контексте №2 гораздо проще иметь дело с несколькими наборами патчей от разных людей.

Ответ 3

Честно говоря, я предпочитаю git более svn в основном потому, что он смехотворно быстр и потому что он дает вам больше (опасную) силу, как бороться с коммитами, и имеет довольно приличное слияние.

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

И github потрясающий. В самом деле. Высокий.

Таким образом, непосредственным преимуществом модели распределенного репозитория git является то, что вы можете локально хранить весь репозиторий, и это делает вещи невероятно быстрыми. И вам не нужно беспокоиться о том, что ваш полпути совершает все закручивать. (альтернативно, вам не нужно проходить боль от ветвления в svn)

Ответ 4

С распределенными системами управления версиями каждая рабочая копия представляет собой собственный репозиторий (и собственную ветку). В любое время вы можете синхронизировать изменения с другими репозиториями. Проекты, которые используют такой контроль версий, часто имеют один или несколько репозиториев, которые являются "основными" ветвями. Но каждый может поддерживать альтернативный репозиторий.

Ответ 5

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

Ответ 6

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

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

Для больших проектов с большим количеством пользователей это отличная возможность.

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

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

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

Ответ 7

У вас очень часто есть центральный репозиторий "благословенного" состояния вашего кода с помощью Git. Это просто, что вы можете настроить еще много макетов репозитория/вкладчика, чем с SVN.

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

Проще говоря: все, что может сделать SVN, Git может, а затем и некоторые. (Дайте или возьмите несколько деталей: Git не имеет svn: externals или блокировки файлов, например.)

Я использую IntelliJ IDEA, а его поддержка Git является первоклассной. Кроме того, Git уже поставляется с довольно мощными интерактивными инструментами, встроенными в графическую и командную строку. Я считаю, что меньше использую IDE.

Ответ 8

Я вижу два основных преимущества для Git над SVN:

• Нет единой точки отказа. Сегодня GitHub пошел, и многие жаловались, но они могли продолжать работать со своими командами, потому что каждая проверенная копия - это полный репозиторий, который может быть diff'd, слит и т.д.

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

Ответ 9

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

Просто потому, что VCS децентрализована, не мешает вам иметь одну, авторитетную ветвь. Все ветки равны, но вы по-прежнему будете поддерживать "официальный багажник" для включения релизов. Например, хотя они являются тысячами ветвей кода Linux, ветвь Линуса выпускается как "официальная" версия.

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