Хорошим примером того, кто подходит под это описание, может быть менеджер проекта.

На днях мой босс спросил меня: «Что это за Github и почему это важно?» У него есть несколько проприетарных проектов, поэтому ему понадобится частный хостинг, и я с трудом могу объяснить что-то необычное: VCS делают совместную работу тривиальной, обеспечивают историю и «резервное копирование» всех ваших данных и позволяют записывать элементарные изменения в базе кода. , По-моему, я думал: «Это почти как если бы вы использовали DRVS, чтобы действительно понять, насколько это выгодно».

Я закончил тем, что указал ему на BitBucket, потому что они дают вам неограниченные частные репозитории (мне даже пришлось объяснить, что это за репозиторий).

У кого-нибудь есть действительно хорошие конкретные примеры того, как VCS спасла свою задницу или сделала жизнь проще и т. Д. - в основном, как бы вы продали DVSC кому-то, кто не знаком с программированием, но не программистом по профессии?

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

1. Резервное копирование . Если ничего другого, это резервное копирование на стероидах. У вас есть вся история разработки, каждый коммит представляет собой снимок всего вашего кода с идентификатором (номером ревизии), описанием, отметкой времени, информацией о пользователе. И это просто для сравнения файлов между ревизиями. Если ничего другого, это быстрее, чем простая резервная копия (только изменения файла отправляются и сохраняются), и содержит гораздо больше полезных метаданных. Зачем изобретать это?

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

3. Поиск и исправление ошибок . Когда ваши клиенты сообщают об ошибке для конкретной версии продукта, вы можете быстро получить фактический снимок источника, чтобы воспроизвести и исправить его. Трудно воспроизвести ошибки, если ваш источник отличается от источника клиента. Вы просите их прислать исполняемый файл, чтобы вы могли разобрать его? Кроме того, если у вас есть проблемы с выявлением причины ошибки, вы можете использовать VCS, чтобы точно определить ревизию, в которой она была внесена.

4. Отслеживание прогресса . Когда вы фиксируете свою работу в моментальных снимках, это позволяет вам (и вашему менеджеру) отслеживать прогресс в реализации функций и статус открытых ошибок. Системы VC также легко интегрируются с системами слежения и системами непрерывной интеграции . Почти невозможно сохранить уровень качества для чего-либо другого, кроме хобби-проекта, если только у вас нет VCS.

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

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

«Вы когда-нибудь находили полезной кнопку« отменить »? О, так вы согласны, что мы должны использовать контроль версий?»

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

Начните с основ:

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

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

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

Эти три вещи должны быть «ею» для продажи VCS - если менеджер не может увидеть достаточную стоимость в указанное время, чтобы найти другого менеджера.

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

СУВ

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

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

DVCSs

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

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

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

Я работаю в основном с инженерами (не разработчиками как таковыми, но они пишут код)

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

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

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

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

У вашего менеджера проекта есть простая цель - выполнять проекты вовремя и в рамках бюджета.

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

Что вам нужно сделать, это объяснить своему руководителю проекта, что команда тратит Xколичество часов каждую неделю, вручную решая проблемы, которые GIT может решить автоматически, или, скажем, в 0.1 * Xколичестве часов разработчика.

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

Мне нравится описание @ Buttons840 как кнопки отмены для базы кода. Это также может помочь сравнить его с (менее разочаровывающей) версией Word или функцией отслеживания изменений InDesign. По моему опыту, это определенно уменьшает необходимость того, чтобы один человек велел другим не трогать файлы X, Y и Z в течение следующих нескольких часов, что удобно для достижения цели.

Я также обнаружил, что детальная информация о версии невероятно полезна для исправления ошибок. Я храню номер версии SVN (через свойство $ Id) почти в каждом файле данных, который я генерирую. Таким образом, если (когда?) Обнаружена ошибка, тривиально идентифицировать файлы с потенциальными проблемами и восстановить их или использовать другой код для компенсации ошибки.

Если вы не используете контроль версий, как вы знаете, как перестроить производственную среду?

1 Разные люди (тестеры, разработчики) будут искать одну и ту же информацию в разных местах

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

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

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

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

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

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

Кроме того, VCS позволяет легко перенести это исправление обратно в новую ветку разработки, если там все еще присутствует ошибка.

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

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

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

При выборе программного обеспечения / библиотек с открытым исходным кодом наличие репозитория DVCS, безусловно, является преимуществом в критериях выбора.

1) Мы можем клонировать весь репозиторий, не нужно беспокоиться о проекте или его сайт мертв.

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