Распределенный контроль версий "приложений-убийц"
Учитывая переход на Mercurial или Git? Мы тоже. В настоящее время я изучаю преимущества DVCS, которые оказываются огромными, жажду и необходимость.
Я хотел бы услышать от сообщества типичные образцы использования.
Давайте создадим список характеристик производительности "Top N" для DVCS (на основе Mercurial, Git или аналогичных).
Пожалуйста, опишите рабочие процессы, которые окажутся продуктивными для вас / вашей команды, процедуры, которые DVCS помог вам достичь / улучшить, а также грубые "хорошие вещи", которые дает вам DVCS (не думайте, что вещи понятны начинающему пользователю).
Я думаю, что такой список может помочь людям приблизиться к команде с предложением DVCS.
Этот вопрос вики сообщества, очевидно.
7 ответов
Единственная настоящая особенность убийцы...
объединение
DVCS (Git, Mercurial или другие) предназначены для слияния (именно потому, что при распределении слияние является ключевой функцией, позволяющей этим инструментам быстро интегрировать код, поступающий из различных удаленных репозиториев).
SVN не подходит для этой задачи (даже сегодня).
Увидеть:
Отделение совершения от публикации
Это важно для более крупных функций, потому что это означает, что можно реализовать серию коммитов для реализации функции (каждый коммит является небольшим и самодостаточным, чтобы легко находить ошибки путем деления истории) на одно собственное удовлетворение и только тогда, когда они готов опубликовать их.
Вариант этого подхода состоит в том, чтобы иметь отдельный общедоступный репозиторий с перебазируемой ветвью с незавершенной работой и отправлять (или отправлять запрос на извлечение) только тогда, когда ветвь готова к проверке.
Похоже, что для нас "приложение-убийца" станет возможностью проталкивать код по этапам.
У нас будет DEV-репо, которое все разработчики проталкивают в него. QA-репозиторий примет push от репозитория DEV и создаст свою версию кода для тестирования. По завершении тестирования они отправляют код в производственное репо (QA-репозиторий является единственным, который может вносить изменения в производственное репо), из которого будет производиться "производственный" выпуск.
Это кратко изложено в hginit Джоэла (в нижней части страницы).
Я обновлю этот пост, как только мы осуществим описанную выше настройку.
Для проектов OSS:
низкий входной барьер, чтобы внести свой вклад
Во-первых, большинство DVCS имеет отличные инструменты для работы с патчами (обычно отправляемыми по электронной почте), как для их создания, так и для их применения. Участник может создать патч, используя любые инструменты (хотя было бы лучше создать патч с DVCS, используемым проектом, так как некоторые DVCS помещают дополнительную информацию в патчи), и отправить его в список рассылки проекта или непосредственно сопровождающему проекта, или прикрепите его к отчету об ошибке / запросу функции в трекере ошибок.
Во-вторых, вам не нужно делать коммит, чтобы иметь возможность внести свой вклад. Просто клонируйте репозиторий проекта, и вы сможете использовать всю мощь DVCS. Затем вы можете отправлять патчи, или запрос на извлечение, или отправку в ветку 'mob'; Есть много возможностей.
Это также является преимуществом для сопровождающего (ых) проекта: ему / ей не нужно беспокоиться о том, кому он может доверять, чтобы предоставить "бит коммита", то есть доступ к репозиторию, как это имеет место в CVCS. Карл Фогель написал в " Создание программного обеспечения с открытым исходным кодом". Как запустить успешный проект свободного программного обеспечения. что для проекта было лучше, чтобы ограничения, такие как контроль доступа, были скорее социальными, чем технологическими; DVCS идет дальше благодаря тому, что не требуется решать, предоставлять ли разрешение на коммит.
Большая часть функциональности доступна в автономном режиме
С централизованными VCS, такими как Subversion, единственное, что вы можете делать в автономном режиме, это редактировать материал. Некоторые системы предоставляют ограниченный доступ к другим функциям (например, в Subversion вы можете перейти к последней версии из репозитория и вернуться к ней), но большая часть того, что делает VCS полезным, это
- чтение истории
- проверить старые версии
- совершение
- создание веток
возможно только если вы подключены к центральному серверу.
При использовании DVCS все вышеперечисленные операции работают локально, и, если что-то требуется для входа на центральный сервер, вы всегда можете отправить его туда позже, когда снова подключитесь к сети.
Хотя это, вероятно, неважно, если вы всегда в сети (например, в офисе), это может иметь решающее значение, если вам часто приходится работать в автономном режиме, например, во время путешествий или дома с ненадежным соединением.
Я начал использовать git специально, потому что я часто работаю в дороге и обычно не имею (надежного) соединения.
Кажется, что "приложение-убийца" является распределенными командами: вместо того, чтобы быть привязанным к центральному серверу (через медленное или ненадежное соединение), каждая команда может иметь свой собственный репозиторий и вносить изменения по мере необходимости.
Поделиться изменениями с другими без публикации
Для меня приложение-убийца, когда я был большой командой, было в состоянии работать вместе с другими инженерами, делиться изменениями, без необходимости проходить через центральный сервер. Это означало, что мы могли обмениваться незавершенными объектами контролируемым образом (т.е. не "копировать этот файл из моего дерева"), и все это просто работало.
- Алиса начинает работу над функцией, но ей нужно, чтобы Боб сделал кое-что перед выпуском.
- Боб принимает изменения Алисы напрямую, заканчивает эту функцию. У Алисы и Боба могут быть проблемы между ними.
- Чарли, специалист по обеспечению качества, берет изменения Боба и Алисы от одного из них. Проверяет их. Они в порядке! Он выталкивает всю партию на главный сервер. Все остальные теперь могут получить эту функцию - завершенную и протестированную.