Головные боли с использованием распределенного контроля версий для традиционных команд?

Хотя я использую и люблю DVCS для своих личных проектов и могу полностью понять, как это облегчает управление взносами в ваш проект от других (например, ваш типичный сценарий Github), похоже, что у «традиционной» команды могут быть некоторые проблемы из-за централизованный подход, применяемый такими решениями, как TFS, Perforce и т. д. (Под «традиционным» я подразумеваю команду разработчиков в офисе, работающих над одним проектом, который никому не принадлежит, и потенциально каждый может прикоснуться к одному и тому же коду)

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

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

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

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

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

Мы используем Mercurial около года. Хотя упомянутая вами головная боль существует, безусловно, самой большой проблемой для полного внедрения для нас было проникновение в мышление DVCS локальных репозиториев (= частое коммитирование). Старый образ мышления «Фиксация после того, как вы отшлифовали код», может быть трудно допустить. идти.

Вы сказали:

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

Установка Mercurial по умолчанию блокирует это поведение. Это не допустит толчок, если в удаленном репо будет создано более одной головы, без дополнительного подтверждения. Для повседневной деятельности мы избегаем этого. (Git назвал головы и каждый может быть обновлен, только если он полностью объединяет предыдущую версию, без дополнительного подтверждения, поэтому снова ситуация не может возникнуть. Другие DVCS также имеют аналогичную защиту.)

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

1. Фиксируйте локальные изменения.
2. Вытащить из центрального репо.
3. Объединить (& совершить объединение.)
4. Толчок к центральному репо.

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

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

Другая проблема, которую вы упоминаете:

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

Это не создает проблему слияния для нас, но может создать другую проблему:

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

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

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

Это моя история, и я придерживаюсь ее, по крайней мере, пару минут ...

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

Как говорит превосходный ответ Джейми Ф. «Рабочий процесс Commit-Pull-Merge-Push, выполняемый регулярно (ежедневно), означает, что если вы ходите по какой-то другой работе, вы видите ее рано - до тех пор, пока она видна, ею можно управлять ,

Проблемы, которые вы описываете, - это больше о том, как вы решили использовать инструменты.

Мы перешли с SVN на GIT 6 месяцев назад после локального использования SVN и GIT в течение нескольких лет. Никто не вернется, и болезненные конфликты слияний остались в прошлом. Мантра «совершай мало и часто» - вот ключ.

Когда я работал в команде, которая использовала git, практическое правило было таким: работай в частной ветке, затем, когда ты будешь готов сделать свою работу доступной для остальной части команды, перед тем, как нажать, перенеси свою ветку на master. (Затем подтвердите свою ветку.)

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

Такой инструмент, как SVN, настоятельно рекомендует тесно интегрированный способ работы.

Т.е. частое принятие в совместно используемую ветку (транк или ветку dev).

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

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

Беспокойство, которое всегда остается в глубине моего сознания, таково: с большой свободой возникает соблазн использовать эту свободу.

Конечно, в моем (ограниченном) опыте я трачу гораздо больше времени, работая независимо в моей текущей команде (используя Mercurial), чем в предыдущих ролях (где мы использовали SVN, CVS & P4).

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

Это не обязательно плохо, но я считаю, что это нужно принимать во внимание.

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

1. Многие местные коммиты
2. Вытащить с сервера
3. Нажмите на сервер

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

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

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

В вашем рабочем процессе вы говорите о людях, которые должны явно обратиться к другому разработчику и сказать ему, чтобы он исправил конфликт, но это не должно быть необходимым. Центральный сервер является «боссом», и с чем вы должны в основном работать. Если ваши изменения относятся к центральному репо, то все в порядке. Если нет, то ВАША задача - устранить конфликт, что может потребовать от разработчика, с которым вы конфликтуете, помочь разобраться в его / ее изменениях. Это то, что вы видите, когда пытаетесь получить / перебазировать с сервера. Так что будьте счастливы совершать и иметь дело с конфликтами, когда вы должны вытащить с сервера.

Принцип работы с централизованным репозиторием тот же, что и при работе с неблокируемой централизованной или распределенной системой:

• В централизованной системе вы:
  1. Получить последнюю версию из mainline ("trunk" в subversion, "master" в git, ...)
  2. Изменить файлы
  3. Объединить изменения с последней версией из основной линии с помощью команды «обновить»
  4. Обязательство по основной линии
• В распределенной системе вы:
  1. Получить последнюю версию с основной линии
  2. Изменить файлы
  3. Совершать локально
  4. Объединить изменения с последней версией из mainline и зафиксировать результат локально
  5. Нажмите на основную линию.

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

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

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

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