Шаг элеватора для Git a / o DVCS - PullRequest
6 голосов
/ 24 марта 2009

Представьте, что у вас есть друг по телефону (не VoIP), который спрашивает: «Что такого особенного в Git? Я в порядке, используя Subversion». Какой будет ваша «высота лифта», чтобы описать преимущество использования DVCS, такого как Git?

Ответы [ 6 ]

2 голосов
/ 24 марта 2009

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

1) Создайте несколько веток разработки из ствола для различных функций, находящихся в разработке.

2) Объединить код из одной ветви функции в другую ветку функции до того, как любая ветка функции будет завершена и готова к объединению в транк.

3) Позже объедините ветви объектов в ствол.

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

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

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

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

2 голосов
/ 24 марта 2009

Был уже вопрос, похожий на этот . Кроме того, у Эрика Синка было число из статей о DVCS . И ответы на другой вопрос, и статьи могут помочь принять обоснованное решение. Простое высказывание о том, что одно лучше другого, вероятно, не поможет (к сожалению, это все, что делает Линус в этом отношении, что на самом деле не помогает убедить людей - по крайней мере, не я :) *

1 голос
/ 24 марта 2009

Это проблема blub .

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

1 голос
/ 24 марта 2009

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

0 голосов
/ 25 марта 2009

Для разработчика наиболее важным отличием между DVCS и SVN является скорость .

Когда команда, которая занимает 30 секунд или 4 минуты в SVN, вместо этого занимает 1 или 2 секунды в Git, Mercurial или Bazaar, это огромная разница для разработчика. Контроль версий становится второстепенной задачей, а не прерыванием вашего рабочего процесса. Вам не нужно добавлять кофеин и повторно вызывать ваш павловский ритуал для того, чтобы приступить к работе; Вы сохраняете фокус, не теряя его.

Другие преимущества важны, но для сравнения они вторичны:

  • более простое, более гибкое ветвление и объединение, с меньшим количеством более простых конфликтов объединения
  • свобода, ограниченная доступом к сети и временем работы сервера
  • структура репо, соответствующая вашему рабочему процессу
0 голосов
/ 24 марта 2009

Два слова: слияние, ветвление.

Слияние и ветвление в Git проще, чем где-либо еще. Git нужно было решить одну проблему: объединить код, написанный тысячами разработчиков, которые редко бывают в одной и той же редакции. Теперь попробуйте это в SVN:

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

Это может быть сделано с SVN, но в Git это режим работы по умолчанию и, следовательно, самый простой.

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