Как децентрализованная система контроля версий улучшает рабочий процесс? - PullRequest
3 голосов
/ 02 марта 2012

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

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

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

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

Обновление:

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

Ответы [ 5 ]

3 голосов
/ 02 марта 2012

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

Если вы когда-либо работали с несколькими разработчиками над одним проектом с использованием SCM, вы должны знать, что объединение - это проблема № 1приходится иметь дело с.Предполагая, что вы смотрели видео, вы уже знаете, что Линус пошел на все, чтобы подробно остановиться на этом вопросе, и почему это главная проблема с другими SCM.

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

Скажем, есть 3 разработчика, включая вас, работающие над проектом, который состоит из 3 частей.Вы все эксперты в отношении частей, над которыми вы работаете.Предполагая, что вы были назначены ответственным за хранилище, два других разработчика могут попросить вас объединить код в основную ветку.НО!Вы не являетесь экспертом в том, над чем они работали, и вам не обязательно нужно понимать, как работает их код ... но вы уверены, что внесенные ими изменения в порядке.С помощью git вы можете переложить ответственность (читай: работа) на слияние с ними.После того как они извлекли ваш код, слили в него свой код и зафиксировали его, они могут попросить вас извлечь объединенный код.

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

2 голосов
/ 02 марта 2012

Я постараюсь ответить на заданный вопрос

Сортировка версии

Любая DVCS сама по себе НЕ улучшает рабочий процесс.Итак, на вопрос "Как?"быстрый и простой ответ «Ни в коем случае!»

Более длинная версия

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

Сразу же при запуске я вижу одно большое преимущество DVCS для бизнеса - оно позволяет P2P-коммуникацию между разработчиками, уменьшая таким образом потери времени в режиме CVCS.

Где это может быть полезнои просили?В любое время, когда 2+ разработчики работают над связанной, но изолированной от «основной» задачи.Представьте себе

  • какую-то систему с ядром и внешним интерфейсом и разделенными зонами ответственности (coredev не касается внешнего интерфейса, frontman не может ничего сделать с ядром)
  • один репозиторий для основного и переднего,без внешних репозиториев (все-в-одном)
  • небольшая работа впереди требует изменения ядра
  • front-файл находится в /views/default/main/lib.js, core-file / core/ db / connectors / engine (но расположение в глубине не имеет реального значения в нашем примере)

SVN-версия, режим ветвления на операцию

  • Frontman работает сWC, связанный с веткой "branch / lib2-frontend" ( not sparse copy), когда "дерьмо случается"
  • Coredev создает ветку "branch / lib2-fixes", успешно выполняет изменения,commit
  • Фронтмен следит за репо и ждет окончательных коммитов от Coredev
  • Фронтмен должен как-то получить обновленные файлы для своей работы и.Запустите mergevoodoo magic
  • Если все в порядке, фронтмен должен устранить каким-либо образом коммит из core-файла coredev в своем коммите

DVCS-версия

Story isне сильно короче и отличаются в 1 месте - когда у coredev есть законченная работа, филиал доставляется фронтмену, объединяется локально.Позже объединенная работа может быть разветвлена, очищена и разделена на готовые к публикации для публичного использования (сбор вишни, переписывание истории и т. Д.)

2 голосов
/ 02 марта 2012

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

Таким образом, вы можете исправить все свои ошибки и несовместимости интеграции локально, затем отправить их.1005 *

1 голос
/ 02 марта 2012

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

Где бы я ни использовал Git, как лично (Github), так и на $ work, в основном это централизованная модель. Однако единственное преимущество, которое я вижу в децентрализованной модели, - это скорость. Я уверен, что гораздо быстрее совершить несколько раз в течение дня локально , а затем вызвать push в центральном репо в конце дня Сравните это (скорость) с ежедневным выполнением нескольких коммитов в удаленном хранилище.

0 голосов
/ 02 марта 2012

Я запутался, что ты здесь пытаешься понять?По сути, вы говорите: «Я знаю, почему Git - это здорово», а затем продолжаете спрашивать: «Почему Git - это здорово?»Такое ощущение, что на самом деле это не вопрос или, по крайней мере, вопрос, который довольно неоднозначен в том, о чем его просят.

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

Пример: скажем, Джо работаетна «проекте А», и я также работаю над проектом А. Джо и я могу сойти с ума, делая коммиты, рефакторинг, и т. д., и т. д., но в конце дня все еще комбинируем наш код (это по сути модель Github- вы создаете проект, делаете сумасшедшие вещи, но поскольку ваша копия является клоном оригинала, всегда можно легко объединить ваши изменения с оригиналом).

Но я чувствую, что пропустило чем вы спрашиваете.

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

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